On Mon, Mar 23, 2015 at 03:30:23PM +0100, Antoine Pitrou wrote:
On Mon, 23 Mar 2015 07:22:56 -0700 Toshio Kuratomi <a.badger@gmail.com> wrote:
Building off Nick's idea of a system python vs a python for users to use, I would see a more useful modification to be able to specify SPYTHONPATH (and other env vars) to go along with /usr/bin/spython . That way the user maintains the capability to override specific libraries globally just like with LD_LIBRARY_PATH, PATH, and similar but you won't accidentally configure your own python to use one set of paths for your five python apps and then have that leak over and affect system tools.
I really think Donald has a good point when he suggests a specific virtualenv for system programs using Python.
The isolation is what we're seeking but I think the amount of work required and the added complexity for the distributions will make that hard to get distributions to sign up for. If someone had the time to write a front end to install packages into a single "system-wide isolation unit" whose backend was a virtualenv we might be able to get distributions on-board with using that. The front end would need to install software so that you can still invoke /usr/bin/system-application and "system-application" would take care of activating the virtualenv. It would need to be about as simple to build as the present python2 setup.py build/install with the flexibility in options that the distros need to install into FHS approved paths. Some things like man pages, locale files, config files, and possibly other data files might need to be installed outside of the virtualenv directory. Many setup.py's already punt on some of those, though, letting the user choose to install them manually. So this might be similar. It would need to be able to handle 32bit and 64bit versions of the same library installed on the same system. It would need to be able to handle different versions of the same library installed on the same system (as few of those as possible but it's an unfortunate cornercase that can't be entirely ignored even for just system packages). It would need a mode where it doesn't use the network at all; only operates with the packages and sources that are present on the box. And remember these two things: (1) we'd be asking the distros to do a tremendous amount of work changing their packages to install into a virtualenv instead of the python setup.py way that is well documented and everyone's been using for ages. it'll be a tough sell even with good tooling. (2) this theoretical front-end would have to appeal to the distro maintainers so there would have to be a lot of talk to understand what capabilities the distro maintainers would need from it. -Toshio