This is pretty much what I often discuss with a friend of mine. Like you he always tells me to use RPM/APT instead of the Python stuff. But my goal is not that the stuff runs as clean as possible on one specific system, but that it runs on as many OS's as possible in relatively clean manner. If virtualenv doesn't tell my Ubuntu's APT that it installed some Python packages in ~/.virtualenv/project_one then an Ubuntu sysadmin will cry and try to kill me, I really don't care. On the other hand with virtualenv I can make sure, that my team leader can run the same command lines as myself and get my Python project running on his Suse box and the QA department can run my code on their Fedora as well. This is why I use Python and this is why I use virtualenv. I'm not happy with how things are in Python, but if I compare the problems between both solution paths currently I still think I'm better off with virtualenv and co.
I was just saying it is good to be aware of RPMs and APT packages. Even old and crusty setuptool has RPM support.
$ python setup.py bdist_rpm
(add deps setup.cfg and make sure to have a MANIFEST.in file to add extra data besides python packages to the RPM package).
You seem to need multiple OS-es. That is hard and I haven't found a clean universal solution.
It also depends on the software. We have lots of mixed, C/C++/Node.js/Java/Python/big data files. Using virtinst/pip, then unpacking tar.gz, make ; make install , then java's (whatever it has) then npm all to setup a repeatable dev and test environment would be a horrible mess. That is what RPMs packages provide for us.
This is pretty much what hynek was on about (see my comment below) and what the guys at Parcel are doing (Iam a johnny come lately with pyholodeck) but we are trying to do the same thing - build once, package into apt/deb and deploy many times.
I think the argument above (boss runs different OS) is a fallacy - you want to deploy to the same target OS, probably in the cloud, so optimise for that first then fiddle with different OS. I guarantee people will prefer deploying a cloud server and logging in "just to see" and be happy with manually bringing things up with `setup.py develop` locally.
The code I write is a framework for testers and developers, though. So it won't run on many similar machines but on many very individual machines. But I guess it might even be possible to transform APT/RPM packages in each other and my guess would be that even yum can read one or the other, even if it's not its main package format (don't know Fedora very well).
You guys really got me excited about this. If I can get any air soon, I'll try to learn more about it!
