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

[Nick Coghlan]

On 21 March 2015 at 22:19, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Sat, 21 Mar 2015 21:52:34 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On 19 March 2015 at 07:51, Donald Stufft <donald at stufft.io> wrote:
>> > I’ve long wished that the OS had it’s own virtual environment. A lot of problems
>> > seems to come from trying to cram the things the OS wants with the things that
>> > the user wants into the same namespace.
>>
>> I'm more wanting to go in the other direction and suggest to folks
>> that if they're not *scripting the OS*, then the system Python isn't
>> what they want, and they should be using at least a virtual
>> environment,
>
> So that defeats the whole point of having a system distribution.

Given how many of the operating system packages are written in Python,
it really doesn't - system administrators getting to use Python to
script the OS is a secondary purpose, the system Python installation
is mostly there to make the OS itself work (if it wasn't for that,
migrating the system Python to Python 3 would have been a lot
simpler!).

In my view, running system independent applications in the system
Python is at best a tertiary purpose - many of those apps (especially
web services) *don't want* to be using system modules at all, which is
why virtualenv switched to disabling the global site-packages by
default.

> I don't have any stakes in Debian / RedHat etc., but that sounds
> a little bit ridiculous to me ;-) On the other hand, perhaps it would
> allow ditching any requests to keep code compatible with old versions
> such as 2.6.

That's exactly the reason for the preference - unless they're
specifically wanting to script RHEL/CentOS 6 or a similar long term
support version at this point, ideally folks should be able to use
Python 2.7 as their baseline version by now. RHEL/CentOS 7 are both on
2.7, while Python 2.7 has been available for RHEL/CentOS 6 by way of
software collections for a couple of years now.

When Python 2 goes EOL upstream in 2020, the standard 10 years of
support on RHEL 7 will still have 4 years left to run - I'd prefer to
see most folks migrated to a Python 3 software collection by then (or
failing that, at least to the Python 3 stack Slavek is aiming to get
into EPEL 7).

Unfortunately, as far as I am aware, Debian Stable and Ubuntu LTS
don't yet have a distro-endorsed equivalent of
softwarecollections.org, and it's not yet clear if running on a faster
moving base distro in a Docker or Rocket container will be an adequate
alternative.

I believe SCLs moved over to using Linux environment modules as the
backend tech in 2.0 (for compatibility with existing HPC
environments), so it should likely be possible to adapt them to work
with APT in addition to RPM, but that requires finding folks both
interested in doing the technical work, as well as in making the case
for SCLs as a feature in the relevant distros (they're a large enough
departure from the traditional mode of operation of a Linux distro
that it took a long time to find a stable upstream home for the
ongoing maintenance of SCLs for the Fedora/RHEL/CentOS ecosystem -
primary maintenance responsibility finally landed earlier this year as
a CentOS SIG)

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia