5 ms·

He mentions not checking the env directory into git. Why not? In general what are the best practices for using virtualenv with version control?

afandian 14y ago
What if you want to perform a security update for one of the libraries on the server? Also, IIRC the environment will contain a symlimk to the python executable and companion files. That symlink will change depending on the environment.
kingrolo 14y ago
Keep your requirements file checked in, but not the virtualenv. The built env should be seen as disposable, and is both location (ie, path on disk) and platform (for libs which are not pure python) specific . I keep my virtualenvs in ~/.virtualenvs/, away from the project.
cinquemb 14y ago
You could have issues with other people not running the same version of python, also you might have different site packages if you are working on an experimental branch that will be pushed or merged later.
almost 14y ago
Virtual envs don't relocate well, they tend to be very specific to machine and even install location. Plus you can recreate them from your requirements.txt file so there's no need. Just add the env directory to your .gitignore
arnarbi 14y ago
I find it best to keep virtual envs completely away from the project (I use http://virtualenvwrapper.readthedocs.org/en/latest/ http://virtualenvwrapper.readthedocs.org/en/latest/ which puts them by default in ~/.virtualenvs). A virtualenv is completely machine-specific. If your project is a package itself (i.e. it has a setup.py file), then use that file to specify dependencies. On a new machine I check out a copy, create a virtual env and activate it. Then in the local copy I run "pip install -e .". This installs all the requirements from setup.py in the virtualenv, and links the local copy of my project to it as well. Now your package is available in the virtual env, but fully editable. If your python project is not a package, you can install its dependencies in a virtual env with pip. Then run "pip freeze" to generate a list of all installed packages. Save that to a text file in your repository, e.g. ``requirements.txt``. On a different machine, or a fresh venv, you can then do "pip install -r requirements.txt" to set everything up in one go.
- turtle4 14y ago
  Alright, so after I set up the environment using pip and virtualenv, I see it has python in it, etc. If I use pip freeze > requirements.txt, it lists the packages I have installed using pip, but it doesn't list anything for the python version itself. How do I make sure the right python version gets captured if I don't check in the /env/ folder?
  - hcarvalhoalves 14y ago
    > How do I make sure the right python version gets captured if I don't check in the /env/ folder? Document it in setup.py: if sys.version_info < (2, 6, 0): sys.stderr.write("Foo requires Python 2.6 or newer.\n") sys.exit(1) You're using setup.py, right? ;)
  - grosskur 14y ago
    Heroku allows specifying the Python version in a file called runtime.txt, which is analogous to requirements.txt: https://devcenter.heroku.com/articles/python-runtimes I think this works well as a convention even if you're not deploying to Heroku. I also like the suggestion to put a guard in setup.py that checks sys.version_info.
metaphorm 14y ago
check in your requirements.txt file and run pip install -r requirements.txt on whichever machine you've just cloned the git repo to.
peterwaller 14y ago
Re: "Why not?" Generally you should strongly avoid putting generated artefacts into version control. This leads to complete pain if ever you find yourself trying to diff or merge when they inevitably change. The problem is that you end up with conflicts which are completely unnecessary - you should always be able to just regenerate the virtualenv at any time. This is especially true for non-relocatable artefacts (as others have mentioned) such as virtualenvs or compiled binaries. Another thing is that these generated artefacts can be costly in terms of space consumed in the repository - maybe not so much for a virtualenv with one package in it, but for binaries or larger virtualenvs, these things can become quite large. In addition they're often not so friendly for git's delta compression which is better suited for textual data. You can end up unnecessarily increasing the size of your repository significantly, which is another thing best avoided.

afandian 14y ago

What if you want to perform a security update for one of the libraries on the server? Also, IIRC the environment will contain a symlimk to the python executable and companion files. That symlink will change depending on the environment.

kingrolo 14y ago

Keep your requirements file checked in, but not the virtualenv. The built env should be seen as disposable, and is both location (ie, path on disk) and platform (for libs which are not pure python) specific . I keep my virtualenvs in ~/.virtualenvs/, away from the project.

cinquemb 14y ago

You could have issues with other people not running the same version of python, also you might have different site packages if you are working on an experimental branch that will be pushed or merged later.

almost 14y ago

Virtual envs don't relocate well, they tend to be very specific to machine and even install location. Plus you can recreate them from your requirements.txt file so there's no need. Just add the env directory to your .gitignore

arnarbi 14y ago

I find it best to keep virtual envs completely away from the project (I use http://virtualenvwrapper.readthedocs.org/en/latest/ http://virtualenvwrapper.readthedocs.org/en/latest/ which puts them by default in ~/.virtualenvs). A virtualenv is completely machine-specific. If your project is a package itself (i.e. it has a setup.py file), then use that file to specify dependencies. On a new machine I check out a copy, create a virtual env and activate it. Then in the local copy I run "pip install -e .". This installs all the requirements from setup.py in the virtualenv, and links the local copy of my project to it as well. Now your package is available in the virtual env, but fully editable. If your python project is not a package, you can install its dependencies in a virtual env with pip. Then run "pip freeze" to generate a list of all installed packages. Save that to a text file in your repository, e.g. ``requirements.txt``. On a different machine, or a fresh venv, you can then do "pip install -r requirements.txt" to set everything up in one go.

turtle4 14y ago
Alright, so after I set up the environment using pip and virtualenv, I see it has python in it, etc. If I use pip freeze > requirements.txt, it lists the packages I have installed using pip, but it doesn't list anything for the python version itself. How do I make sure the right python version gets captured if I don't check in the /env/ folder?
- hcarvalhoalves 14y ago
  > How do I make sure the right python version gets captured if I don't check in the /env/ folder? Document it in setup.py: if sys.version_info < (2, 6, 0): sys.stderr.write("Foo requires Python 2.6 or newer.\n") sys.exit(1) You're using setup.py, right? ;)
- grosskur 14y ago
  Heroku allows specifying the Python version in a file called runtime.txt, which is analogous to requirements.txt: https://devcenter.heroku.com/articles/python-runtimes I think this works well as a convention even if you're not deploying to Heroku. I also like the suggestion to put a guard in setup.py that checks sys.version_info.

metaphorm 14y ago

check in your requirements.txt file and run pip install -r requirements.txt on whichever machine you've just cloned the git repo to.

peterwaller 14y ago

Re: "Why not?" Generally you should strongly avoid putting generated artefacts into version control. This leads to complete pain if ever you find yourself trying to diff or merge when they inevitably change. The problem is that you end up with conflicts which are completely unnecessary - you should always be able to just regenerate the virtualenv at any time. This is especially true for non-relocatable artefacts (as others have mentioned) such as virtualenvs or compiled binaries. Another thing is that these generated artefacts can be costly in terms of space consumed in the repository - maybe not so much for a virtualenv with one package in it, but for binaries or larger virtualenvs, these things can become quite large. In addition they're often not so friendly for git's delta compression which is better suited for textual data. You can end up unnecessarily increasing the size of your repository significantly, which is another thing best avoided.