Nested virtual environment support in site/venv modules

[dmatech1]

Feature or enhancement

Proposal:

It's a bit of a niche use case, but it would be helpful if you could have one virtual environment be created that references another as its parent. If you currently attempt to do this, the pyvenv.cfg of the child virtual environment only indirectly references the parent through the command variable (which doesn't appear to be used). The code in site.venv could be enhanced to infer the prefix of the parent environment and add those site packages after the current virtual environment. This would ensure that the order of sys.path entries would be appropriate.

This would allow you to create a group virtual environment with a lot of common packages and still allow users to have their own child environments with additional or newer packages.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

[ajuancer]

This is a minor feature, which does not need previous discussion elsewhere

Is it? Virtual environments are meant to be isolated.

I understand the benefit of reducing redundancy and storage but introducing hierarchical dependencies means

• child environment is no longer truly independent
• If the parent environment is updated, the child environment may break unexpectedly
• Users may assume their environment is self-contained, but it actually depends on the parent

for example, pip freeze would list the child libraries, or both parent and child libraries?

[dmatech1]

We already have that issue with pip freeze when the environment is created with --system-site-packages, and this is presumably why it has these options. It appears that the --local option only shows packages directly in that environment (based on prefix).

  -l, --local                 If in a virtualenv that has global access, do not output globally-installed packages.
  --user                      Only output packages installed in user-site.

Interestingly, pip install from within that environment will let you install to user-site if you don't have write access to the environment and --system-site-packages is enabled, but pip uninstall from within that environment will refuse to uninstall those packages as they're outside the environment. Basically, the goal is to create a main environment owned by a service account and separate accounts for each user that reference this one to allow for additional packages. I could probably do this myself with a sitecustomize module that uses site.getsitepackages(), site.addsitedir(), re-ordering entries in sys.path, and adding a value to site.PREFIXES. Things would be initialized in the wrong order, but that probably wouldn't matter.

[ajuancer]

The usecase has convinced me... seems quite common so many people could benefit of it. It would be interesting even writing it in the documentation