To follow up: virtual environments for different python versions

[tomneep]

In this section we have a reason for using virtual environments

You have an older project that only works under Python 2. You do not have the time to migrate the project to Python 3 or it may not even be possible as some of the third party dependencies are not available under Python 3. You have to start another project under Python 3. The best way to do this on a single machine is to set up two separate Python virtual environments.

I thought that each python version managed its own dependancies anyway so I'm not sure that this is entirely accurate e.g. if I were to do python2 -m pip install xyz and python3 -m pip install xyz they'd end up in different places anyway? So I'm not sure the point they're trying to make here (even if using an venv for each wouldn't be the worst thing)?

There is also this callout

A SPECIFIC PYTHON OR PACKAGE VERSION IS ONLY EVER INSTALLED ONCE

Note that you will not have a separate Python or package installations for each of your projects - they will only ever be installed once on your system but will be referenced from different virtual environments.

I'm not sure that is true either? If I make two virtual environments and install matplotlib into each of them then it looks like each one of them has a copy of the files?

[tomneep]

The second of the two questions should probably become a separate issue but here is a test

$ mkdir two-venv-test && cd two-venv-test
$ du -sh
  0B	.
$ python3 -m venv venv{1,2}
$ du -sh
 25M	.
$ source venv1/bin/activate
$ (venv1)  python -m pip install matplotlib
...
$ (venv1)  du -sh
119M	.
$ deactivate 
$ source venv2/bin/activate
$ (venv2)  python -m pip install matplotlib
...
$ (venv2) du -sh
214M	.

[kkh451]

Suggested solution for "reason for using virtual environments". Rather than Python 2 vs Python 3 - emphasise a deprecated vs non-deprecated Python version https://devguide.python.org/versions/:

Updated version:

You have an older project that only works under Python 3.8. You do not have the time to migrate the project to Python 3.14 or it may not even be possible as some of the third party dependencies are not available under Python 3.14. You have to start another project under Python 3.14. The best way to do this on a single machine is to set up two separate Python virtual environments.

[kkh451]

I agree that venvs contain the actual dependencies rather than links and so it isn't correct to say they are only installed once.

• https://www.reddit.com/r/learnpython/comments/14fwlny/how_do_people_manage_virtual_environments_so_that/?
• https://www.infoworld.com/article/2257028/python-virtualenv-and-venv-dos-and-donts.html
• https://www.reddit.com/r/Python/comments/wvx0tj/multiple_copies_of_the_same_package_using_virtual/

Suggested solution for references to venvs containing "links" to dependencies, rather than actual dependencies:

Section: [1.2 Virtual Environments For Software Development - Virtual Environments] https://carpentries-incubator.github.io/python-intermediate-development/instructor/12-virtual-environments.html#virtual-environments

Updated version:

Python virtual environments are implemented as directories with a particular structure within software projects, containing  specified dependencies allowing isolation from other software projects on your machine that may require different versions of Python or external libraries.

Then remove the callout

:::::::::::::::::::::::::::::::::::::::::  callout

## A Specific Python or Package Version is Only Ever Installed Once

Note that you will not have a separate Python or package installations for each of your projects -
they will only ever be installed once on your system but will be referenced
from different virtual environments.

::::::::::::::::::::::::::::::::::::::::::::::::::
```