> Python actually has another, more primitive, package manager called easy_install, which is installed automatically when you install Python itself.<p>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.<p>Also, while the quick skim of the rest of this looks mostly good, there's some unnecessary advice which complicates things.<p>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").<p>What beginners (and even some more experienced programmers) need to learn about is <i></i>--user<i></i>. 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.<p>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.<p>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.
Want to make life even easier? Check out virtualenvwrapper.<p><a href="http://virtualenvwrapper.readthedocs.org/en/latest/" rel="nofollow">http://virtualenvwrapper.readthedocs.org/en/latest/</a><p>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.
Man, global system-wide installations that require admin rights by default? That's certainly something! Quite the stark comparison to Node.js and npm, where everything is installed locally into the current directory (under node_modules) by default, and "global" installation is actually a per-user installation. Tricking pip with virtualenv seems to get you pretty close to what you get by default with npm, albeit still somewhat more clunky. But to be fair, most other package managing solutions seem to pale in comparison to npm :-)<p>Either way, nice article. Now if only most packages weren't still for Python 2... PyPI says it has 30099 packages total, but only around 2104 of them are for Python 3 (according to the number of entries on the "Python 3 Packages"-page[1]).<p>[1] <a href="https://pypi.python.org/pypi?:action=browse&c=533&show=all" rel="nofollow">https://pypi.python.org/pypi?:action=browse&c=533&sh...</a>
If you're in Brighton in the UK and you like this then maybe you'll be interested in the one day workshop run by Jamie (author of the blog post) and myself. This post was actually based on some of the material written by Jamie for the course.<p>Next one is happening next Thursday and there are still a couple of tickets:<p><a href="http://dabapps.com/services/training/python-for-programmers" rel="nofollow">http://dabapps.com/services/training/python-for-programmers</a>
"pip is vastly superior toeasy_install for lots of reasons, and so should generally be used instead."<p>Unless you are using Windows, as pip doesn't support binary packages.
Nice article, but after using leiningen (the clojure solution to a similar problem, based on maven), it's really hard to go back to something like this. I really, really wish there was an equivalent in python (really, every language I use).
I would like to just give a difference advice regarding creating virtualenvs and installing dependencies:<p>When you create the virtualenv, the <i>current</i> package you're working on doesn't get added to site-packages, so you're forced to be at the repository root to import the package.<p>The best approach is to have a proper setup.py file so you can do `python setup.py develop`, which will link the package you're working on <i>into</i> the virtualenv site-packages. This way it acts as it's installed and you can import anyway you like.<p>If you define your requirements on the setup.py (I think you should), you can even skip the `pip install -r requirements.txt` step.<p>I've cooked up a package template that can help getting this working:<p><a href="https://github.com/hcarvalhoalves/python-package-template" rel="nofollow">https://github.com/hcarvalhoalves/python-package-template</a>
I'd like to know what the best practices with regards to security are for using pip, or installing packages in general.<p>How do you verify package integrity? Do you simply pray that PyPI isn't compromised at the moment, or do you download your packages from Github instead, because the main repositories have more eyeballs on them?<p>How do you do security updates with pip?<p>I'm using apt-get at the moment which gives me security updates AFAIK, but my need is growing for more recent versions and certain packages that aren't accessible with apt.
<p><pre><code> Python actually has another, more primitive, package manager called
easy_install, which is installed automatically when you install Python itself.
pip is vastly superior to easy_install for lots of reasons, and so should
generally be used instead. You can use easy_install to install pip as follows:
</code></pre>
I found it quite ironic that the author says pip is "vastly superior" to easy_install and then proceeds to install pip using easy_install.
Thanks for the article! I recently spent some time going through the process of learning VirtualEnv / Pip; after looking at several tutorials, agreed that this is one of the better ones out there. A few other things I saw in other articles that you might like to clarify (though I understand there's a tradeoff with simplicity/clarity).<p>(1) specifically state that `pip freeze` is how to create requirements file (as folks have said in comments already)
(2) add "further reading" link on VirtualEnvWrapper, as it adds some convenience methods to ease use of VirtualEnv
(3) the "yolk" package shows you what's currently installed; it can be helpful to `pip install yolk` then run `yolk -l` to view the different packages installed in each of your envs.
(4) when installing a package, you can specify the version, e.g. `pip install mod==1.1`, whereas `pip install mod` will simply install the latest
For Mac, am I better off with Homebrew?<p><a href="http://docs.python-guide.org/en/latest/starting/install/osx/#install-osx" rel="nofollow">http://docs.python-guide.org/en/latest/starting/install/osx/...</a><p><a href="https://github.com/mxcl/homebrew/wiki/Homebrew-and-Python" rel="nofollow">https://github.com/mxcl/homebrew/wiki/Homebrew-and-Python</a>
a good introduction - I would like to hear more about deployment with virtualenv though - is it expected that you just document any packages with requirements.txt and then you would create the virtualenv in the deployment target and set everything up again? Or can you "package" a virtualenv for deployment?
Calling env/bin/python directly, as opposed to `source activate` is very handy for things like:<p>* bash command line<p>* cron<p>* or daemon manager like supervisord
Speaking as someone relatively new to Python (coming from an embedded development background, mostly with C/C++): What's the standard way of distributing client-side programs/libraries? If you only have one script you can just put it in /usr/local/bin/ but otherwise you have to mess with the system site-packages or modify sys.path before importing, right? I've seen a surprisingly large number of distros that didn't check /usr/ <i>and</i> /usr/local/ for packages.<p>Do you just hand the user an automatic virtualenv script? (Outside of using one of the binary builders out there, obviously.)
Some of the mentioned problems with the traditional method are partially solved with `pip install requests --user` but I understand that the bigger problem/main reason for virtualenv isn't helped by this.<p>However, I was very surprised that the author didn't mention venv (<a href="http://docs.python.org/3.3/library/venv.html" rel="nofollow">http://docs.python.org/3.3/library/venv.html</a>) at all since it is basically virtualenv but part of the Python standard library.
VertualEnv seems less like a brilliant tool than it does a workaround for an architectural problem in Python and pip.<p>That said, dependency hell is <i>always</i> tricky, and I've had to deal with some far uglier solutions in other platforms.
Excellent tutorial, new to python, and I always hated when things just install without letting you know where it's going..and next time there is some upgrade all sorts of weird errors keep coming..Thanks a lot.
Thanks for this article, it was definitely needed. I've known that I should be using virtualenv for a while now, but actually trying to figure it out has been somewhat daunting until now.