Environment Manager for More than Just Python
This whole virtualenv thing is pretty cool, but it has always seemed too specific to Python for me. Let me see if I can explain. At first I had no use for virtualenv whatsoever, I could just sudo apt-get install python-whatever and get what I needed. As my distro got older and I didn't want to update my whole system, I started using virtualenv and pip to install and manage python packages instead of apt. It's great, except that the postgresql packages that came with my distro were getting crusty too. Because postgresql is not a python package, I get no help from virtualenv. Does anyone else have this problem? How do you deal with it?
This reminds me of a very old problem from the chip design (EDA, ASIC design, whatever you want to call it) world. To design chips you buy licenses for expensive simulators and synthesis tools, and those tools are constantly being revved, fixing old bugs, introducing new features, and unfortunately, introducing new bugs. Because of that you never ever upgrade from one version to the next, you always install a whole new copy of each version, and then you manipulate your PATH and other environment variables that the tools use according to which version you want to experiment with today. I once worte a tool that's not too different from virtualenv if you squint a little, but it was more generic for managing your unix environment in general. It was great for dealing with all the versions of chip design tools we used. Unfortunately it's locked inside the company I wrote it for. I have since discovered that an open source project very similar to the one I wrote exists, but it uses far too much tcl ;-)
I started an open source project to try and tackle this again (before I had used virtualenv, actually), and I have wondered if it could solve this general problem for not just python. It's pretty raw, but you can see it here.
If you browsed around that project, you can see I haven't gone very far with it. It works for me, but it needs some love to make it easier for others to get up an running with it. I'm more than open to questions on how to install and use it, feedback on the design and usage model, and to contributions from others.
This reminds me of a very old problem from the chip design (EDA, ASIC design, whatever you want to call it) world. To design chips you buy licenses for expensive simulators and synthesis tools, and those tools are constantly being revved, fixing old bugs, introducing new features, and unfortunately, introducing new bugs. Because of that you never ever upgrade from one version to the next, you always install a whole new copy of each version, and then you manipulate your PATH and other environment variables that the tools use according to which version you want to experiment with today. I once worte a tool that's not too different from virtualenv if you squint a little, but it was more generic for managing your unix environment in general. It was great for dealing with all the versions of chip design tools we used. Unfortunately it's locked inside the company I wrote it for. I have since discovered that an open source project very similar to the one I wrote exists, but it uses far too much tcl ;-)
I started an open source project to try and tackle this again (before I had used virtualenv, actually), and I have wondered if it could solve this general problem for not just python. It's pretty raw, but you can see it here.
If you browsed around that project, you can see I haven't gone very far with it. It works for me, but it needs some love to make it easier for others to get up an running with it. I'm more than open to questions on how to install and use it, feedback on the design and usage model, and to contributions from others.
Comments
At home I use Gentoo so if I want the more recent goodness in the system permanently I just bump the ebuild in my overlay. At work where I run and develop for Ubuntu we just backport the package, add it to our autobuild infrastructure and install from overlay apt repos.