4 ms·

$ 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 linke

by lloeki 14y ago

$ 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.

kiwidrew 14y ago
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)"
slig 14y ago
Better yet, use virtualenvwrapper and don't worry about cluttering your project folder.
- pyre 14y ago
  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.
  - slig 14y ago
    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?
    - cdr 14y ago
      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.
redouane 14y ago
just add env to .gitignore
tocomment 14y ago
So do you use virtualenv in production? Is there a good tutorial on this for my developers?
- pyre 14y ago
  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.
- irahul 14y ago
  > 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 http://code.google.com/p/modwsgi/wiki/VirtualEnvironments You can also execfile the activation script, but I prefer changing sys.path.
- tocomment 14y ago
  What's the benefit of using virtualenv in production? And actually what's the benefit in general?
  - adolph 14y ago
    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 http://www.virtualenv.org/en/latest/index.html
    - AUmrysh 14y ago
      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.
veeti 14y ago
FYI, --no-site-packages is default nowadays.
ehutch79 14y ago
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.
parham 14y ago
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 https://github.com/skinnyp/djan-n-go

by lloeki 14y ago

kiwidrew 14y ago

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)"

slig 14y ago

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

pyre 14y ago
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.
- slig 14y ago
  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?
  - cdr 14y ago
    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.

redouane 14y ago

just add env to .gitignore

tocomment 14y ago

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

pyre 14y ago
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.
irahul 14y ago
> 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 http://code.google.com/p/modwsgi/wiki/VirtualEnvironments You can also execfile the activation script, but I prefer changing sys.path.
tocomment 14y ago
What's the benefit of using virtualenv in production? And actually what's the benefit in general?
- adolph 14y ago
  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 http://www.virtualenv.org/en/latest/index.html
  - AUmrysh 14y ago
    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.

veeti 14y ago

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

ehutch79 14y ago

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.

parham 14y ago

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 https://github.com/skinnyp/djan-n-go