3 ms·

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 lon

• jonafato 12y ago
  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 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.
• acdha 12y ago
  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.
  • clebio 12y ago
    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.
    • acdha 12y ago
      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.