Can you have a virtual environment based on a virtual environment?
-
We're curious. A virtual environment can use system wide resources, but can a virtual environment lean on an existing venv and only have the extra bits, or overide bits, that are specific to that new venv?
cheers Chris Maunder
-
We're curious. A virtual environment can use system wide resources, but can a virtual environment lean on an existing venv and only have the extra bits, or overide bits, that are specific to that new venv?
cheers Chris Maunder
-
We're curious. A virtual environment can use system wide resources, but can a virtual environment lean on an existing venv and only have the extra bits, or overide bits, that are specific to that new venv?
cheers Chris Maunder
The virtual environment just puts itself (i.e its version of Python and associated libraries) at the front of the search path. So anything called after you run
activate, will load first from the.venvlocations, before looking at the system folders. I guess that if you then activate another.venvthen the search path would bevenv2 -> venv1 -> system installation. Which could be fun. -
The virtual environment just puts itself (i.e its version of Python and associated libraries) at the front of the search path. So anything called after you run
activate, will load first from the.venvlocations, before looking at the system folders. I guess that if you then activate another.venvthen the search path would bevenv2 -> venv1 -> system installation. Which could be fun.I guess I could do this manually, since it's only really the site-packages I'm worried about. Something like Suppose I have two apps that have different and potentially conflicting packages. I'd create a venv with the python interpreter in /app/bin/python and the common packages in /app/bin/python/site-packages-common. I'd then install specific packages for app A and B in different folders:
/app/bin/python
/app/bin/python/site-packages-common
/app/bin/python/site-packages-A
/app/bin/python/site-packages-Bthen in app A I could do ```python sys.path.insert(0, "/app/bin/python/site-packages-common") sys.path.insert(0, "/app/bin/python/site-packages-A") ``` and in app B I could do ```python sys.path.insert(0, "/app/bin/python/site-packages-common") sys.path.insert(0, "/app/bin/python/site-packages-B") ``` I would have to specify the target folder when running pip to install the packages (no drama). My big concern is if we have the following: ``` pip install common-package -target /app/bin/python/site-packages-common pip install package-a -target /app/bin/python/site-packages-A pip install package-b -target /app/bin/python/site-packages-B ``` What if package-a relies on v1 of common-package, and package-b relies on v2 of common-package? I'm actually assuming pip will install all dependent packages anyway, so while we might end up with repeated installs of dependant packages, there are certainly some 'common' packages that won't necessarily be dependencies of anything and so will only be installed once in the common folder
cheers Chris Maunder
-
I guess I could do this manually, since it's only really the site-packages I'm worried about. Something like Suppose I have two apps that have different and potentially conflicting packages. I'd create a venv with the python interpreter in /app/bin/python and the common packages in /app/bin/python/site-packages-common. I'd then install specific packages for app A and B in different folders:
/app/bin/python
/app/bin/python/site-packages-common
/app/bin/python/site-packages-A
/app/bin/python/site-packages-Bthen in app A I could do ```python sys.path.insert(0, "/app/bin/python/site-packages-common") sys.path.insert(0, "/app/bin/python/site-packages-A") ``` and in app B I could do ```python sys.path.insert(0, "/app/bin/python/site-packages-common") sys.path.insert(0, "/app/bin/python/site-packages-B") ``` I would have to specify the target folder when running pip to install the packages (no drama). My big concern is if we have the following: ``` pip install common-package -target /app/bin/python/site-packages-common pip install package-a -target /app/bin/python/site-packages-A pip install package-b -target /app/bin/python/site-packages-B ``` What if package-a relies on v1 of common-package, and package-b relies on v2 of common-package? I'm actually assuming pip will install all dependent packages anyway, so while we might end up with repeated installs of dependant packages, there are certainly some 'common' packages that won't necessarily be dependencies of anything and so will only be installed once in the common folder
cheers Chris Maunder
I've never come across a situation which would need A and B to co-exist in that way, so it's difficult to give a useful answer. But unless you are running A and B at (more or less) the same time in the same shell, do you really need to share between them?