11–20 of 86 posts
Next one is happening next Thursday and there are still a couple of tickets:
He mentions not checking the env directory into git. Why not? In general what are the best practices for using virtualenv with version control?
Just add the env directory to your .gitignore
Unless you are using Windows, as pip doesn't support binary packages.
However, I was very surprised that the author didn't mention venv (http://docs.python.org/3.3/library/venv.html) at all since it is basically virtualenv but part of the Python standard library.
It's actually not, it's part of setuptools/distribute, though some Python distributions (actually just brew that I know of) include distribute alongside Python.
Also, while the quick skim of the rest of this looks mostly good, there's some unnecessary advice which complicates things.
virtualenv is not necessary if the crux of the advice is "don't install packages globally" (which is fantastic advice, second probably to the more important advice "don't install stuff with sudo").
What beginners (and even some more experienced programmers) need to learn about is --user. You install packages with `pip install --user thing`, and they become per-user installed (be sure to add `~/.local/bin` to your `$PATH`). This is enough to not require sudo and for 99% of cases is actually sufficient.
There is a rare case where you actually have packages that depend on different, conflicting versions of another dependency. This has happened ~1 time to me.
Don't get me wrong, I like virtualenv for other reasons (relating to workflow and maintenance), but if we're teaching people about packaging, there's no particularly great reason to dedicate most of a tutorial on it.
http://virtualenvwrapper.readthedocs.org/en/latest/
Lots of benefits, but trading 'cd path/to/my/project && source env/bin/activate' for 'workon project_env' (with autocomplete) is alone easily worth the five seconds it takes to check it out.
> Python actually has another, more primitive, package manager called easy_install, which is installed automatically when you install Python itself. It's actually not, it's part of setuptools/distribute, though some Python distributions (actually just brew that I know of) include distribute alongside Python. Also, while the quick skim of the rest of this looks mostly good, there's some unnecessary advice which compli…
He mentions not checking the env directory into git. Why not? In general what are the best practices for using virtualenv with version control?
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.
Want to make life even easier? Check out virtualenvwrapper. http://virtualenvwrapper.readthedocs.org/en/latest/ Lots of benefits, but trading 'cd path/to/my/project && source env/bin/activate' for 'workon project_env' (with autocomplete) is alone easily worth the five seconds it takes to check it out.
That said, dependency hell is always tricky, and I've had to deal with some far uglier solutions in other platforms.