I don't know how to completely solve this problem, but here is something that can alleviate it considerably.
If you have a recent version of pip, you can use wheels [1] to save built packages locally. First create a new virtualenv and install the common packages. Then put these packages in a wheel directory. Then, for any other virtualenv that need the common packages, you can easily install then from the wheel directory (this is fast even for numpy & friends, because nothing will be compiled again) [2]. # Create a new virtualenv virtualenv myenv source myenv/bin/activate # Install the wheel package pip install wheel # Install your common packages pip install numpy scipy matplotlib # Create a requirements file pip freeze > /local/requirements.txt # Create wheel for the common packages pip wheel --wheel-dir=/local/wheels -r /local/requirements.txt Now you have all the built packages saved to /local/wheels, ready to install on any other environment. You can safely delete myenv. Test it with the following: # Create a virtualenv for a new project virtualenv myproj source myproj/bin/activate # Install common packages from wheel pip install --use-wheel --no-index --find-links=/local/wheels -r /local/requirements.txt [1] https://wheel.readthedocs.org [2] http://www.pip-installer.org/en/latest/cookbook.html#building-and-installing-wheels 2013/8/9 Luca Cerone <luca.cer...@gmail.com> > Dear all, is there a way to "nest" virtual environments? > > I work on several different projects that involve Python programming. > > For a lot of this projects I have to use the same packages (e.g. numpy, > scipy, matplotlib and so on), while having to install packages that are > specific > for each project. > > For each of this project I created a virtual environment (using virtualenv > --no-site-packages) and I had to reinstall the shared packages in each of > them. > > I was wondering if there is a way to nest a virtual environment into > another, > so that I can create a "common" virtual environment that contains all the > shared packages and then "specialize" the virtual environments installing > the packages specific for each project. > > In a way this is not conceptually different to using virtualenv > --system-site-packages, just instead of getting access to the system > packages a virtual environment should be able to access the packages of an > other one. > > Thanks a lot in advance for the help, > Luca > -- > http://mail.python.org/mailman/listinfo/python-list >
-- http://mail.python.org/mailman/listinfo/python-list