CODEWITHSUNDEEP
pythongitvirtualenv
GreenAsJade
GreenAsJade

Reputation: 14685

Is there a reason not to check in the virtualenv environment along with the source code of a python project?

I'm following the instructions for setting up to work with Python on a Mac (http://docs.python-guide.org/en/latest/starting/install/osx/)

It suggests to store the virtual environment created by virtualenv in the project directory... which is of course a git repo.

Is there any reason not to add the virtualenv to the git repo? It seems the natural thing to do, but ...

Upvotes: 7

Views: 2437

Answers (3)

Martijn Pieters
Martijn Pieters

Reputation: 1123940

Always try to check in the source, not the result of running a process.

A virtualenv is rather platform specific; a Windows virtualenv may require different binaries than one created on Linux. The paths in the script files will almost certainly use absolute paths, not relative paths, tying a virtualenv to a specific location on your harddisk.

Instead, check in instructions on how to recreate a virtualenv. Include the commands, and use tools like pip, zc.buildout or Pipenv to let others recreate the right environment for their platform.

pip lets you install packages into a virtualenv with a requirements.txt file. You'd commit that file. zc.buildout lets you define complex build configurations in .cfg files. Commit those. Pipenv tracks the top level dependencies in Pipfile and creates a Pipenv.lock file for perfectly reproducible environments, check in these two files, etc.

Upvotes: 10

taleinat
taleinat

Reputation: 8721

Just describe the project's dependencies in a requirements.txt file and keep that versioned under git along with the project's code etc. It is easy to re-create the environment afterwards: just run pip install -r requirements.txt. It's a really concise and clear way to manage a project's dependencies.

One reason not to keep the environment itself in the repo is that it will increase the repo's size significantly, which over time will make working with your git repo slow (especially cloning it).

There are many other reasons, of course...

Upvotes: 2

user395760
user395760

Reputation:

Philosophically, the virtualenv isn't source code, it's a bunch of reproducible artifacts. It shouldn't be checked in, at most a script to re-create it more easily should be checked in.

Practically, a virtualenv is completely unportable even within a single system (can't move it without breaking stuff), much less across different systems with the same general set up (binary paths and ABIs might be different), let alone different operating systems (do I really have to explain this one?). So checking it in actually costs you time in virtually every case (because you can't use it after cloning the repository).

Upvotes: 8

Related Questions