Hacker News Reader

Comment by lloeki | Hacker News Reader

    $ git add .

Wait, what? No!

This will add the whole venv, which contains symlinks, scripts with shebangs, and potential binaries, and as such is totally linked to your system, so this definitely breaks if your python ends up in another location or you're entirely on another OS.

What should be done is

    virtualenv env --no-site-packages
    echo "/env" >> .gitignore
    pip freeze > requirements.txt

So when you want to restore/deploy you'd do

    git clone foo
    cd foo
    virtualenv env --no-site-packages
    source ./env/bin/activate
    pip install -r requirements.txt

I'm not even considering the issues regarding the presented git workflow. If one wants to semi-automate a git workflow, one would rather use git-flow instead of this prepare_deployment hack.

View on HN

A hook that I've found useful (though not perfect -- esp. when working on many branches) is to check that "pip freeze" and requirements.txt match before allowing a commit. My hgrc has the following line for this:

    [hooks]
    pretxncommit.pip = bash -c "diff -u requirements.txt <(source env/bin/activate && pip freeze)"

Better yet, use virtualenvwrapper and don't worry about cluttering your project folder.

While I agree with the virtualenvwrapper suggestion, the idea that a single directory is going to 'clutter' your project folder is pushing the definition of 'clutter' to me.

Doesn't pip create other folders (one being "build", don't remember the others) in the root of the virtualenv whenever it has to compile something?

bin/, include/, lib/, share/, tmp/ etc last I knew.

I've been using virtualenvwrapper since the separate virtualenv dir feature was added (and before), though. Seriously - just use virtualenvwrapper.

FYI, --no-site-packages is default nowadays.

I wrote a script a while ago that takes care of setting up a similar structure to the django project described and also takes care of issues such as the one you've described. https://github.com/skinnyp/djan-n-go

So do you use virtualenv in production? Is there a good tutorial on this for my developers?

I don't think there is any 'best practice' as of yet. It ranges from just running virtualenv, and then using pip + requirements.txt on deploy, to packaging up your virtualenv in a .rpm/.deb and installing via your distro's package manager.

> So do you use virtualenv in production? Is there a good tutorial on this for my developers?

Using virtualenv in production mostly boils down to `pip -r reqs.txt -E virtual_env`(in place of pip install -r reqs.txt) and making sure virtualenv path is the first in sys.path http://code.google.com/p/modwsgi/wiki/VirtualEnvironments

You can also execfile the activation script, but I prefer changing sys.path.

What's the benefit of using virtualenv in production? And actually what's the benefit in general?

The basic problem being addressed is one of dependencies and versions, and indirectly permissions. Imagine you have an application that needs version 1 of LibFoo, but another application requires version 2. How can you use both these applications? If you install everything into /usr/lib/python2.7/site-packages (or whatever your platform’s standard location is), it’s easy to end up in a situation where you unintentionally upgrade an application that shouldn’t be upgraded.

From: http://www.virtualenv.org/en/latest/index.html

Additionally, you may run into a problem where your distribution only offers certain versions of python and its packages, when you need newer versions. On systems like CentOS, this becomes a bit more complex as you can wind up in 'dependency hell' trying to compile everything you may need for a complex python program. virtualenv and pip make this very easy to manage and set up.

or better yet, keep anything no part of the project out of the project's directory. if you don't intend on distributing it, it doesn't belong there.

just add env to .gitignore

Reply on news.ycombinator.com