can not load system-site-packages when using a venv ipykernel

[ruiy326]

Environment data

• VS Code version: 1.67.1
• Jupyter Extension version (available under the Extensions sidebar): v2022.4.1011282140
• Python Extension version (available under the Extensions sidebar): v2022.6.1
• OS (Windows | Mac | Linux distro) and version: Windows 19044.1645
• Python and/or Anaconda version: 3.8.10
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): venv
• Jupyter server running: Local

Expected behaviour

fail to import a module installed in %userprofile% in *.ipynb files but it works in *.py files.

I have set 'include-system-site-packages = true' in pyvenv.cfg.

Actual behaviour

failed with ModuleNotFoundError

Steps to reproduce:

1. create a virtual enviroment. then install ipykernel.
2. import a module installed in %userprofile% in *.ipynb files.
3. run a cell.

Logs

Output for Jupyter in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Jupyter)

XXX

[rchiodo]

Thanks for the bug.

Can you print out the sys.path in a notebook and the sys.path in a python terminal and show the difference here?

We should be picking up the pyvenv.cfg settings so I'd like to see what the difference is.

[DonJayamanne]

@rchiodo we don't load system wide global packages in non global python paths. this is by design.

[rchiodo]

@DonJayamanne are you saying we remove them? I just thought we didn't add them to the list. But we don't change them, do we?

[DonJayamanne]

We do remove them.

I just thought we didn't add them to the list

Thats correct, this is made possible by removing them from the list.

[rchiodo]

Why do we remove them? This was because conda environments were picking up the wrong stuff?

[DonJayamanne]

his was because conda environments were picking up the wrong stuff?

Sorry for not explaining that, yes thats correct. We found that it completely messes up things. And decided not to add it.
This is the first time we've had a user complain about this, seems legitimate though.
I guess we could add this back if its a non-conda and virtual environment. Then again there are a number of different virtual environments, are poetry considered virtual? We need to be careful in adding them, else we could end up adding them even for environments that would never get them regardless.

I'd suggest just adding this back only for virtual environments (venv, virtualenv, virtualenvwrapper, etc).
We used to have startup code that did this, which was later removed.

[ruiy326]

@DonJayamanne @rchiodo Thanks for your replies. When using VScode 1.66.2 with jupyter 2022.2, I had noticed that a venv ipykernel can not be started if any dependent packages are inherited from the global python path. But then a global package can still be used in a virtual enviroment.
I didn't expect sharing global packages to be removed. So I submitted this bug.

[greazer]

We think we can honor adding this request by reading the pyvenv.cfg file and if the system site packages is set to true, we append site package path.

[rchiodo]

@ruiy326 did you mean to close this? We plan on fixing this soon.

[greazer]

Resolving as dupe of #9995