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

[Gregory P. Smith]

On Wed, Mar 18, 2015 at 9:48 AM Barry Warsaw <barry at python.org> wrote:

> On Mar 18, 2015, at 05:31 PM, Victor Stinner wrote:
>
> >Does it work to pass command line options to Python in the shebang?
>
> Yes, but only one "word", thus -Es or -I.
>
> We've often mused about whether it makes sense to have two Pythons on the
> system.  One for system scripts and another for users.  System Python
> ('/usr/bin/spython' perhaps) would be locked down and only extensible by
> system packages.  On Debuntu that might mean no /usr/local on sys.path.  It
> would also have a much more limited set of installed packages, i.e. only
> those
> needed to support system functionality.
>

I recommend this. It'd be nice to see a common OS distro actually do it.

For a system-only Python lockdown you should remove distutils and pip to
prevent anyone from easily installing anything that isn't a distro package
into it. Possibly even removing its site-packages directory and sys.path
entry all together (things your distro needs to install could mix directly
with the stdlib packages)


> /usr/bin/python2 and /usr/bin/python3 then would be user tools, with all
> the
> goodness they currently have.
>
> It's never gotten much farther than musings, but protecting the system
> against
> the weird things people install would be a good thing.  OTOH, this feels a
> lot
> like virtual environments so maybe there's something useful to be mined
> there.
>

While people sometimes suggest virtualenv as a solution for this. It isn't
really the same thing. It isn't a hermetic clone of the original
interpreter.  It copies the main binary but symlinks back to much of the
stdlib.  So any existing virtualenv can be an out of date unsupported mix
of both after the original interpreter is updated. This has caused users
problems in the past with some minor version updates where an internal
non-public API used between some binary and a stdlib module was updated as
part of a bugfix. Suddenly they didn't match up for existing virtualenvs.

virtualenv is an amazing hack that I promote to most anyone for their own
applications use with the occasional known caveats (solvable by regurly
rebuilding your virtualenvs)...  But I wouldn't want to see it used for the
core OS itself even though it sounds better at first glance.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150323/fd7ee20d/attachment.html>