Hacker News new | past | comments | ask | show | jobs | submit login

Virtualenv is a half solution and a hack. Use vagrant and VMs. There's a whole sea of libs and software that isn't "versioned" by pip/virtualenv.

supervisord is the wrong solution. It answers the wrong question (is the process running). It's worse than useless in that it has given false positives. The right question is (is the process responding correctly). Use monit or something else that actually does what's needed.




Vagrant ist nice for testing but I’m not going to deploy services to VirtualBox (we use kvm for that). Of course there are dependencies outside of the Python ecosystem but their influence proved to be negligible till now. YMMV.

supervisor is not a an alternative to monitoring, I never claimed that. But that’s a whole different story.


virtualenv isn't just used for testing, though. it's widely used to isolate applications' python environments/dependencies from one another.


Why would you want to virtualise an entire system when your dependencies are restricted to a bunch of Python modules?


Personally I would just go for Virtualenv, but you'd be surprised if you know people do with virtualization. I've mostly seen it in Windows shops, but it's by no means limited to that. A common "anti-pattern" I've seen is to build a vmware image, or set of images, that run your "environment". Developers then spin up copies and request changes that they need be made to the "master copy".

When it's time to test and deploy, the code is deployed to a vmware image, which is then sent to the testers. When everything checks out, the code is once again deploy to a new copy of the image, which is then promoted to production.

On argument we've seen is that it makes it easy to do a rollback of the system, using vmware snapshots. It might be a sensible idea in some cases, I just thing it's a bit weird and some overhead.

The worst use case of this I've seen is a Telco, where you needed to spin up as much 12 vms, depending one what you and your teams was working on. But then again that's the same company that read the Perforce guidelines on recommended setup and still decided to just pill all the projects in to one repository.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: