Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

v6.3.0 introduced pkg_resources side effects

Aperta
#824 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
jupyter-notebook, python
Ambito
backend

Direzione di ricerca

Inizia dal commit 470145ca7d103bdf6081bcfde09933ab81a56a5b e segui l’importazione attraverso debugpy.server.api fino a debugpy/_vendored/pydevd/pydevd_plugins/init.py. Esegui il notebook di riproduzione collegato con ipykernel<6.3.0, ipykernel==6.3.0 e l’head corrente, osservando sys.path e pkg_resources. Il lavoro è completato quando il riproduttore non fallisce più senza una soluzione alternativa specifica per i notebook e qualsiasi impatto sul debugging di pydevd è compreso.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug

ipykernel v6.3.0, I believe 470145ca7d103bdf6081bcfde09933ab81a56a5b specifically, introduced an indirect import on the pkg_resources module, via debugpy.server.api.

During this import, debugpy imports pkg_resources (here).

The pkg_resources module has some import-time side-effects that cause problems in complex notebooks:

It’s important to note that the global working_set object is initialized from sys.path when pkg_resources is first imported, but is only updated if you do all future sys.path manipulation via pkg_resources APIs.

I am filing this with ipykernel because I believe it's the place we start caring about the sys.path manipulations - it is somewhat common for notebooks to include !pip install foo steps, which impacts sys.path without using the pkg_resources APIs. However, I'd like to discuss where a fix should live.

I'm part of the TensorFlow docs team, and we have an increasing number of notebooks that have a "restart runtime" requirement (e.g.). I don't think fixing every notebook is the right solution, and we could apply a fix in our own infrastructure, but I would favour a fix at the root, if possible.

When we fix it in the notebook, we reload the module (e.g.), however we should unload the module completely if we fix this before any notebook code, in case the notebook uses pkg_resources. If we were to do this, say, in ipykernel, would it impact the notebook kernel or other environment factors? e.g. in the use of pydevd or debugging?

In case it helps, this notebook can be used to reproduce the failure. ipykernel<6.3.0 works, but ipykernel==6.3.0 (and at head) fail.

Lingua principale
Python
Stelle
734
Fork
411
Merge medio
1g 2h
PR unite (30g)
9

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ipython/ipykernel

Tutte le issue di ipython/ipykernel

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.