Hacker News Reader

Comment by coldtea | Hacker News Reader

The real world.

That's the same real world where I routinely type "mkvirtualenv …", install a bunch of things and don't notice that I've been using Python 3 until the first time I toss a print statement in for debugging?

Which virtualenv's, regrettably, depend on OS-level packages. so when you go to deploy your app to production, you find you installed some system dependency long ago and promptly forgot about it. The real world is messy.

I'm not arguing there aren't upgrading pains, but --no-site-packages has be on by default in virtualenv for over three years (https://virtualenv.pypa.io/en/latest/changes.html#id31). There are certainly issues when it comes to compatibility between the languages, but I'm not sure that's one of them any more.

I've actually done this for years in the real-world. Yes, you can make mistakes. No, it's not a particularly hard problem to avoid and, as jonafato noted, --no-site-packages has been the default for awhile and I had it enabled by default for many years before then.

If this is a frequent challenge, it sounds like there's some technical debt to pay down elsewhere in your testing/deployment practice because it really doesn't need to be that hard.

I could be doing something wrong; I'm open to the possibility. And yet...

`psycopg2` is a pip package that won't install without system dependencies. Yes, I use Ansible and the system dependencies are managed. But, out of the box, on a clean system, `pip install psycopg2` doesn't just work.

The approach I use is to have the non-python dependencies managed externally – i.e. use APT/YUM for the postgres, mysql, redis, memcache etc. C libraries since those are very stable on a normal distribution – so a simple `pip install` will work as a non-privileged user inside a virtualenv.

Reply on news.ycombinator.com