Hacker News Reader

Comment by wgrover | Hacker News Reader

This is an interesting take on using virtualenv: "In the last couple months I have adopted the mindset that I will be mostly avoiding installing python packages into the global 'site-packages', as I've found that it pays to manage dependencies on more of a per-project basis, rather than globally installing, and hoping all goes well."

This appeals to me, but are there good reasons for avoiding installing packages to site-packages?

View on HN

> This appeals to me, but are there good reasons for avoiding installing packages to site-packages?

There's a (pardon the language, but I don't know a better term) shitfight between OS packages and Python packages for control of the global site packages. Each will override the other.

My current setup, which works very well: use pip and virtualenv for everything, leave the global site packages alone.

Everything you need to run Ubuntu this way can be achieved by:

apt-get install python-dev python-pip python-virtualenv virtualenvwrapper

Then mkvirtualenv, workon, and pip to your hearts content.

I find the main benefit of project-specific site-package directories is simply that it's easy to see what my project depends on and what it doesn't. If everything's mixed together in the global dir then it's not always obvious. This becomes important when you want to deploy your project somewhere other than your personal PC.

It's also very useful for managing different versions of packages - e.g. I can upgrade to the latest Django for one project without risking breaking all of the others.

Having said that, I install the stuff that I consider to be "core" globally - for me that's primarily numpy, but also a handful of others.

The same reason that you don't make all variables global.

Reply on news.ycombinator.com