[Python-Dev] Use ptyhon -s as default shbang for system python executables/daemons

[Toshio Kuratomi]

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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150323/66af199f/attachment.sig>