Virtual env installs libraries for your program/web service/etc.
Those libraries will eventually need security updates.
On Linux for example, which hosts most servers, you upgrade python libraries with yum update/apt-get update/you-name-it.
Single central package database, security updates are marked as security, makes upgrades easy and you never miss one.
With VirtualEnv your dependencies are installed outside the score of the package manager. It means you have to keep track of security updates yourself.
If you don't, and one lib has a well known security bug, you'll be hit and you most likely had no chance to update because "you didn't know".
That's why I'm asking. I know a lot of companies hosting python things and using VirtualEnv because "its easy", but they entirely discard updates. I'm not sure that is wise. I was hoping someone had a solution.
> On Linux for example, which hosts most servers, you upgrade python libraries with yum update/apt-get update/you-name-it.
Not really. In many cases distro provided packages are unsuitable, either because they are just outdated, or because they have some strange patches merged in. So people are already managing their python packages with pip, virtualenv makes it easier.
If you want to use distro packages, then virtualenv allows you to use those (it does that by default). You only need to install into virtualenv those libraries that are unavailable/unusable from distro packages.
> I know a lot of companies hosting python things and using VirtualEnv because "its easy", but they entirely discard updates.
Discarding updates (without due care) is bad sysadmining regardless of what kind of package management is in use. Virtualenv is no magic bullet, nor is it an excuse for sloppy procedures.
So what you're proposing it tracking security updates manually and update your libraries?
As much as it's hackish, it's possible to update virtualenv's libs. But tracking the security update is another story.
If not tracking hundred of libs manually is bad sysadmining, well, I'd like you to be my sysadmin and track them.
There's even a bigger issue here: many of those libs have zero tracking. That means even if their author fixes a security bug in the source, he probably won't mark it.
And you, not being a sloppy sysadmin, how will you deal with that? It's pretty obvious to me that you just don't deal with it.
Then one day one of those libs will be widely used, have a bad bug and everyone will scour their systems to update.. but of course the damage will already have been done.
It's pretty common to deploy Python apps via a virtualenv. In most cases you will use something like a pip requirements.txt or fabfile for Fabric to define how to deploy your app and what are the dependencies. The file is tracked in version control along with the rest of your project.
If at some point you need to upgrade one of the libraries due to a security vulnerability, you would change the dependency in the requirements file and roll out a new version of your app to all your servers.
If you have multiple apps, then repeat the process for each app.
Generally it would be a bad idea to rely on a single installed version because often times the API can change between versions and different apps may target different versions of a library. It's preferable that each one has its own dependencies isolated in a virtualenv unless you have a really rigorous process for keeping all your apps updated to the latest library versions.
Your parenthetical is just wrong. The setup for a new virtualenv requires access to the internet, iff you choose not to a) bundle the packages in a libs dir or b) have a locally hosted mirror of pypi or c) have the libs in your system packages already or d) a dozen other things.
Of course this is true for setting up any development environment. You have to get the dev environment from somewhere at some point to bootstrap the process.
Your entire parentheical screams FUD, and obviously disingenuous FUD at that.
