> 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 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.
> 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.
Is this relevant advice for packages needed by your web server account, e.g. www-data?
Thanks, this is great advice. easy_install comes preinstalled on a Mac, which is where the confusion arose. Will update the article when I get a chance.
As I install/develop my python apps into VMs with a fixed python version, I rarely use virtualenv... don't see the need for the extra complexity.
I've eagerly read pieces like this but haven't yet found out the reason this solution is problematic or that I'm doing it wrong. Just that no one else seems to be recommending it. Anyone have an idea?
One other thing I'm not happy about regarding packaging best-practices (and PyPi) is that security updates are not able to be automated leading to vulnerable packages.
Virtualenv is about managing multiple/conflicting versions of libraries, not different versions of Python itself. You're accomplishing the same thing by using a different VM for each app, just with higher overhead and isolation of things other than Python as well.
I recently learned the lesson about global packages. I thought it would be so nice to have all packages readily on hand, but now startup time is about 15 seconds of crawling the filesystem looking for files (over NFS).
Just start using virtualenv for everything. By default virtualenv starts you with a clean python setup each time and nothing you've installed globally with pip will affect you.
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.