<p dir="ltr"><br>
On 24 Mar 2015 07:59, "Gregory P. Smith" <<a href="mailto:greg@krypto.org">greg@krypto.org</a>> wrote:<br>
><br>
><br>
> On Wed, Mar 18, 2015 at 9:48 AM Barry Warsaw <<a href="mailto:barry@python.org">barry@python.org</a>> wrote:<br>
>><br>
>> On Mar 18, 2015, at 05:31 PM, Victor Stinner wrote:<br>
>><br>
>> >Does it work to pass command line options to Python in the shebang?<br>
>><br>
>> Yes, but only one "word", thus -Es or -I.<br>
>><br>
>> We've often mused about whether it makes sense to have two Pythons on the<br>
>> system.  One for system scripts and another for users.  System Python<br>
>> ('/usr/bin/spython' perhaps) would be locked down and only extensible by<br>
>> system packages.  On Debuntu that might mean no /usr/local on sys.path.  It<br>
>> would also have a much more limited set of installed packages, i.e. only those<br>
>> needed to support system functionality.<br>
><br>
><br>
> I recommend this. It'd be nice to see a common OS distro actually do it. <br>
><br>
> 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)</p>
<p dir="ltr">The hard part of this is the complexity in getpath.c and the current difficulty of testing the interaction of all the different configuration settings properly. Completely overriding the standard path setup isn't too bad, it's *partially* overriding it that's hard.</p>
<p dir="ltr">That's really one of the main goals of the proposed startup refactoring in PEP 432 - separating things into distinct phases so the path configuration is easier to customise and so the current behaviour becomes easier to test.</p>
<p dir="ltr">That's a fairly big project with high barriers to entry though, as even just wrapping your head around the current accumulated complexity in the way the default sys.path gets constructed is a time consuming task.</p>
<p dir="ltr">That approach has the virtue of not being a "system Python" specific solution, it's a "make embedding the CPython runtime much easier" solution, with "system Python with different default settings" as the reference use case.</p>
<p dir="ltr">>> /usr/bin/python2 and /usr/bin/python3 then would be user tools, with all the<br>
>> goodness they currently have.<br>
>><br>
>> It's never gotten much farther than musings, but protecting the system against<br>
>> the weird things people install would be a good thing.  OTOH, this feels a lot<br>
>> like virtual environments so maybe there's something useful to be mined there.</p>
<p dir="ltr">For distro level work it would be closer to the environment modules used in high performance computing work (which are also the basis of <a href="http://softwarecollections.org">softwarecollections.org</a>)</p>
<p dir="ltr">Where things get really messy is on the package management side. Either we end up with yet another copy of modules that are often already duplicated between the Python 2 & 3 stacks, or else the relevant user Python needs to be customised to also be able to see the system level libraries for things like Kerberos, interfacing with the package manager, dbus, etc.</p>
<p dir="ltr">The former approach = "ugh, no, just no" as far as I'm concerned, while the latter would be a messy patch to try to carry given the current difficulty of customising and testing the startup sequence.</p>
<p dir="ltr">><br>
><br>
> 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.<br>
><br>
> 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.</p>
<p dir="ltr">Right, this is why Fedora/RHEL/CentOS have software collections instead, and those have their own "gotchas" that currently make them unsuitable for use as the main system Python (for example: the Fedora installer & package manager are both written in Python, so having the main system Python be an SCL would bring SCL support into the minimal package set, which we wouldn't want to do. The typical aim is to find ways to get things *out* of that set, not add new ones)</p>
<p dir="ltr">Cheers,<br>
Nick.</p>