Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

v6.3.0 introduced pkg_resources side effects

Aberta
#824 1 comentário 0 reações 0 responsáveis Ver no GitHub

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
35/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Estagnada
Stack de tecnologia
jupyter-notebook, python
Domínio
backend

Direção de pesquisa

Comece pelo commit 470145ca7d103bdf6081bcfde09933ab81a56a5b e rastreie a importação por debugpy.server.api até debugpy/_vendored/pydevd/pydevd_plugins/init.py. Execute o notebook de reprodução vinculado com ipykernel<6.3.0, ipykernel==6.3.0 e o head atual, observando sys.path e pkg_resources. Está concluído quando o reprodutor não falhar mais sem uma solução alternativa específica para notebooks e qualquer impacto na depuração do pydevd estiver compreendido.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Python
Estrelas
734
Forks
411
Merge médio
1d 2h
PRs com merge (30d)
9

Guia de contribuição

Abrir o guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de ipython/ipykernel

Todas as issues de ipython/ipykernel

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.