4 ms·
Sorry, but I'm not sure I understand your logic. Using virtualenv adds extra complexity, but virtualizing the entire server doesn't? I mean, the only complexi
by j_baker 15y ago
Sorry, but I'm not sure I understand your logic. Using virtualenv adds extra complexity, but virtualizing the entire server doesn't? I mean, the only complexity using virtualenv adds is having to run the virtualenv process once. After that, you can still install to site-packages. You just have to install to a different site-packages directory.
Besides that, it's worth pointing out that using a virtualenv is not a security precaution. It's a precaution to prevent mucking up the global python installation for other packages that run on it. Using linux containers to achieve this seems like overkill.
- lifeisstillgood 15y agoA late reply but I don't just want the python environment virtualised - if it's important enough that I should section off python, then there is a good chance I will want to consider the whole box as a single unit, python, firewall rules, database what ever. I tend to think the unit of abstraction should not be the python process, but the server. This is a little easier to grasp when you think of BSD jails where essentially you can choose to only run those processes that actually mTter - it's less virtualised and os than pick and mix an os. Apologies for late reply - I guess I am straightening it out in my head more than telling anyone else.