I use distribution packages for all my deployments, period. I have no desire to maintain a separate system for installing an upgrading my own applications versus those provided in repositories already. Time to push out a new release? `tito release koji-el7`, SRPM built and sent to Koji to be built and packaged, every 15 minutes mash runs to update our internal yum repo from Koji - and next time Puppet runs the package is automatically upgraded to the latest version without me having to do anything.

No virtualenv's, no tarballs, nothing special beyond an RPM. I won't deploy software any other way (and if something doesn't already have an RPM I will make one for it).

https://ius.io/ is your friend.

Among many things you have all versions of python available that don't conflict with system packages or themselves.

What's awesome is that you can install multiple versions and all of them just work.

Note to self: snuxoll likes pushing boulders up hills by ignoring all the tooling people have invented to make this stuff easy.

> ignoring all the tooling people have invented to make this stuff easy.

I don't, I just use the standard one that comes with the operating system instead of insisting on re-inventing the wheel because "packaging is hard". I could have just had tito push directly to a yum repository if I so desired, but it's much nicer to use Koji (which I'm already familiar with).

> I don't, I just use the standard one that comes with the operating system

...which is "ignoring all the tooling people have invented to make this stuff easy". virtualenv and pip were explicitly designed to work around two damn nigh insurmountable problems:

1) OS vendors move slowly, and 2) Sometimes two projects on the same machine need two different libraries

It's trivial to use virtualenv and pip to make Project A and Project B run side by side with different Python versions and completely different dependency manifests. You can come up with your own ad-hoc system to deal with this or you can adapt the best practice of every other Python shop. Make no mistake though: your current way is deliberately choosing the hard road.

virtualenv is trying to solve a problem that's already solved by setuptools and eggs, and doing a shitty job at it. Back before eggs where a thing, sure, virtualenv had a purpose - but now there's absolutely no need to create a completely independent environment when you can just use pkg_resources.require() or just add the appropriate eggs to sys.path.

Virtualenv doesn't make my life any easier, it makes deploying applications harder since I have to write a custom deployment pipeline - whereas I already maintain RPM's for other non-python software we use internally, and I can use the same infrastructure to handle them both.

Edit: For most of our applications the latest Fedora Server release is also our target host, so "distributions moving slowly" is rarely an excuse as typically the latest packages are available (and if not we make them ourselves, like we do for selenium).

You have mixed up history line.

Eggs are older than virtualenv, from the times of easy_install. Now there are wheels that are nicely integrated with pip.

Also virtualenv became integrated into python (it's called pyvenv now).

They aren't completely decoupled. Even with a virtenv you still need to install and maintain a lot of library and header packages on the host OS.

Well, almost completely. The build dependencies don't change nearly as fast as the application, and are generally backwards compatible.

For complete decoupling, better use NixOS.

Or Docker containers :-)

That's problem which is solved with wheels.

No sense?

What if you are happy with the current version and don't plan on changing it before changing the OS? What if you don't install more than one app on a system, or are using containers? Then you might not need the extra complexity.

Even then. Suppose you want to change the OS for some reason. LTS eventually ends, maybe you want to change out some common library, or whatever. It's nice to have the option.

You could do it when you need it, ala YAGNI.