"Nested" virtual environments

[Marcel Rodrigues]

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.cerone at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20130815/5198a8ea/attachment.html>