Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v6.3.0 introduced pkg_resources side effects #824

Open
markmcd opened this issue Dec 14, 2021 · 1 comment
Open

v6.3.0 introduced pkg_resources side effects #824

markmcd opened this issue Dec 14, 2021 · 1 comment
Labels
Milestone

Comments

@markmcd
Copy link

markmcd commented Dec 14, 2021

ipykernel v6.3.0, I believe 470145c 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.

@blink1073
Copy link
Contributor

@JohanMabille might it be possible to lazily import from debugpy.server import api to avoid the side effects at import time?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants