3

the most common answer to this Question Where do I put my python files in the venv folder? says, that you shouldn't place your own files within the venv directory.

The strongest argument is just not to mix up your own files with foreign files, which is quite weird, because in general developers include a lot of foreign files or code or libraries to not reinvent the wheel. So I think this isn't a real good point.

The other argument is

It provides an isolated environment wherein you can download a different version of python packages and run it for your project. Hence, do not put anything inside your virtual environment. Keep it clean.

I think it is on the contrary the best thing to put your code within the venv:

  • I create my venvs with --copies, so my venv-dir physically contains all the stuff, which is needed to run my actual project code. A python installation is not that big at all.
  • The venv contains exactly the packages (be it downloaded, or self-written general packaged code) in exactly the testet applicable version for the actual project code. Which might or might not fit to other project code as well, but this doesn't matter because everything is just there/optimized/installed for this project.
  • The whole venv directory is under version control, so i might basically uninstall a package even via subversion instead of pip.
  • I could even deploy the whole venv including the project code via svn to another machine (if its "similar enough" of course...) and directly have all i need in one place.

Finally the main argument: My project code will only ever run if the specific venv is loaded, because the general installation doesn't "know" the installed packages within.

So: What is so bad about a source folder within my venv folder if the project code can't run without it anyway?

evilive
  • 916
  • 1
  • 7
  • 24
  • 1
    "because in general developers include a lot of foreign files or code or libraries to not reinvent the wheel" - the fact that your code uses the contents of the venv doesn't mean you should *physically insert* your code into the venv. You've used plenty of things without physically inserting yourself into them, haven't you? – user2357112 Jan 23 '19 at 21:31
  • 3
    The virtual environment folder is analogous to `/usr/lib/python`; it stores files that are imported by, but not *part* of, your code. You don't store your project files in `/usr/lib/python`; don't store them in your virtual environment either. Also: why put the venv folder under source control? It's a derived artifact, created as necessary from something like `requirements.txt` which *can* (and should) be under source control. – chepner Jan 23 '19 at 21:36

1 Answers1

2

code that your code depends on(which is not necessarily python by the way, many packages actually wrap c and c++ code) is sometimes built differently for different hardware and operating systems, once a package is installed it means that it was built for a specific runtime and the environment is bound to the type of system it was installed on.

if you want to "freeze" the state of your application dependencies, a best practice is to use a requirements file which easily enables dependency resolution. Additionally, you can enforce usage of specific python interpreters

if you want to ship an application with assurance it will operate exactly the same way on different systems, I suggest looking at containers

0e1val
  • 481
  • 3
  • 6
  • 1
    Thanks, the argument with "non purely python packages" got me somehow ;) And I even wanted to take a closer look at docker anyway :) – evilive Jan 24 '19 at 21:36