4 ms·

> As long as you run your program using the virtual environment's Python, it gets to use all the modules you installed in the venv. It doesn't matter where the

> As long as you run your program using the virtual environment's Python, it gets to use all the modules you installed in the venv. It doesn't matter where the program is and you don't have to move it from its current location, you just have to change what 'python' it uses. This is common knowledge. People just need to understand that by activating the virtualenv, your path precedence starts with the virtual environment. You can store your environments anywhere you want. You could even have a dev folder with a stack of all the usable virtualenv configuration which you activate as necessary. The same holds for conda. Although with a small caveat - any pip installation that you do with conda by default may end up in the global pip cache. Virtual environment however create their separate isolated pip caches, and hence pretty useful. tldr : virtualenv work anywhere and have a completely isolated set of python packages. Same doesn't hold for conda (unless you're doing conda install instead of pip install).

EE84M3i 5y ago
I think it isn't quite common knowledge that you don't "need" to active a virtual environment to use it. For years, I thought that activating a virtualenv was changing the PATH (so I would get the right binaries in my shell) and another environment variable like PYTHONHOME/PYTHONPATH (so that python would know where to load modules from). It turns out it _only_ sets PATH, which is non-obvious. As far as I can tell, it turns out that there's some additional magic in the python binary so that it "knows" when it's executed from a symlink to try and add ../lib/pythonX.X/site-packages/ to sys.path, but for the life of me I can't find where this is documented how exactly this works.
- pdonis 5y ago
  PEP 405 [1], which added virtual environment support to the Python standard library, documents how the python binary attempts to determine sys.prefix, which is the key thing that has to be set to the virtual environment directory in a virtual environment. See the "Specification" section. [1] https://www.python.org/dev/peps/pep-0405/ https://www.python.org/dev/peps/pep-0405/
  - EE84M3i 5y ago
    Oh! Thank you! that's incredibly helpful. So, does this mean my understanding of "activate" setting PYTHONHOME (and thus being required for using a virtualenv) was true before this PEP was accepted? Looks like python3.3?
    - pdonis 5y ago
      > does this mean my understanding of "activate" setting PYTHONHOME (and thus being required for using a virtualenv) was true before this PEP was accepted? I believe that's what the activate scripts for third-party virtualenv tools did, yes. > Looks like python3.3? Yes, that's the version for which the PEP was accepted.

EE84M3i 5y ago

I think it isn't quite common knowledge that you don't "need" to active a virtual environment to use it. For years, I thought that activating a virtualenv was changing the PATH (so I would get the right binaries in my shell) and another environment variable like PYTHONHOME/PYTHONPATH (so that python would know where to load modules from). It turns out it _only_ sets PATH, which is non-obvious. As far as I can tell, it turns out that there's some additional magic in the python binary so that it "knows" when it's executed from a symlink to try and add ../lib/pythonX.X/site-packages/ to sys.path, but for the life of me I can't find where this is documented how exactly this works.

pdonis 5y ago
PEP 405 [1], which added virtual environment support to the Python standard library, documents how the python binary attempts to determine sys.prefix, which is the key thing that has to be set to the virtual environment directory in a virtual environment. See the "Specification" section. [1] https://www.python.org/dev/peps/pep-0405/ https://www.python.org/dev/peps/pep-0405/
- EE84M3i 5y ago
  Oh! Thank you! that's incredibly helpful. So, does this mean my understanding of "activate" setting PYTHONHOME (and thus being required for using a virtualenv) was true before this PEP was accepted? Looks like python3.3?
  - pdonis 5y ago
    > does this mean my understanding of "activate" setting PYTHONHOME (and thus being required for using a virtualenv) was true before this PEP was accepted? I believe that's what the activate scripts for third-party virtualenv tools did, yes. > Looks like python3.3? Yes, that's the version for which the PEP was accepted.