3 ms·

I'm ditching virtualenvs and going with old good Debian packaging and private APT repository. For VMs/containers that already run a single application, except

I'm ditching virtualenvs and going with old good Debian packaging and private APT repository. For VMs/containers that already run a single application, except for some weird edge cases, there's really no point in having a virtual environment in a virtual environment. I have initial success with a few simpler projects, now looking into transitioning more complex ones. Not sure whenever it'll go without any hassle, but seems worth trying. At worst, I'd just waste my time and return to virtualenvs.

grosskur 12y ago
You could also try virtualenvs inside Debian packages: https://github.com/spotify/dh-virtualenv https://github.com/spotify/dh-virtualenv One reason to keep virtualenvs is that the system Python (VM or container) includes extra Python packages that your app may or may not need. If you use a virtualenv, you exclude these system-installed packages and guarantee a clean starting point.
icebraining 12y ago
Same here. As a bonus, it makes it easy to create a bare-metal OS installation image that includes your app. I'm running a script right now that generates an ISO that turns a brand new machine into a server running our app with a template DB in completely unattended fashion.
calpaterson 12y ago
I find the problem with this approach comes when you want to ship a package (ie: requests) that is newer than whatever is packaged for your OS. Then you either have to repackage OS packages, taking on the corresponding duty to keep them patched. I am using wheel files in production for this very reason