First thoughts: - that's added complexity. - is that reproducible? - how can I detect that that's the case? - a standard way might be easiest - what controls prevent one user from modifying the parent venv and thereby everything that depends upon it? - would there need to be modifications to tools, or do you just manually set VIRTUAL_ENV to the parent? - are there strange effects e.g. when v1 has pkg.this but v2 has removed pkg.this and then `impory pkg.this` still succeeds? On Tue, Oct 20, 2020, 2:24 PM Matthias Bussonnier < bussonniermatthias@gmail.com> wrote:
Hello Python Ideas,
Would there be any interest in upstreaming a patch allowing virtualenv to be inherited in core python ? I'm working with a company that uses such an internal patch and would be ok with me spending some time trying to upstream it.
When creating a venv, this let you point to "parents" venvs that will be used to search for existing packages; thus potentially making the creation of large venvs with a common base faster, and decreasing disk space usage.
I am aware that there are solution around like, https://virtualenvwrapper.readthedocs.io/en/latest/command_ref.html#add2virt..., or modifying PYTHONPATH , but my question is more about whether such a change has a chance of being accepted in Core Python; and whether there is a need for a pep,, or simply a request for enhancement on bpo and a pull-request.
Thanks, -- Matthias _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KTIYUE... Code of Conduct: http://python.org/psf/codeofconduct/