[harryf]

The current version of Redhat - RHEL 7 - which most banks, large enterprises etc. are using comes with a system python version of 2.7.5 and you need to jump through hoops to install Python 3.x ( e.g. https://stackoverflow.com/questions/8087184/problems-install... ), which may not even be possible if you're in an environment where security is tightly controlled.

There is the possibility of Python 3.x being default in RHEL 8 ( https://fedoraproject.org/wiki/Changes/Python_3_as_Default ) but right now RHEL 8 isn't released and there's no date for it being released. And even once it is released, it will be more years before big enterprises really start switching

TLDR ignore python 2.7 and alienate RHEL customers

[derefr]

Developers relying on OS scripting runtimes for their applications are misusing the OS; and environments that only allow the use of OS scripting runtimes are fundamentally misunderstanding their job.

OS scripting runtimes are there for the OS to use, in its system software and services. Such runtimes are not there for anyone else to use. They’re implementation details of the OS.

This is the reason that certain platform-bytecode libraries get packaged into OS packages, while most don’t. Those packages are also there strictly for the OS itself to use, with versioning allowing other OS packages to rely on them. If you’re not writing OS software (e.g. something that runs under init(8), speaks D-Bus, is part of minimal installs, etc.) then you shouldn’t be relying on those packages.

Consider the fact that a lot of “application software” OS packages—packages shipped by the distro!—actually vendor their own runtime and libraries. They do this because they have separate needs from the super-stable-but-minimal runtime provided by the OS.

If not even the distros themselves think it’s worthwhile to rely on the OS runtime for everything, you shouldn’t either.

Unless your software’s relationship with a daemon or library is “I expect that it was already here when I got here, because that exact ABI version of it is part of the definition of the platform we target”—just vendor the dang deps.

Yes, they become your responsibility to audit. The distro was never going to do that job for any software not required to run itself anyway.

[kevinmgranger]

Hoops? Enabling an SCL isn't hard. https://developers.redhat.com/blog/2014/02/18/migrate-to-pyt...

[Spiritus]

>you need to jump through hoops to install Python 3.x

What? You can install Python 3.6 from EPEL[1], takes 5 seconds.

[1] https://fedoraproject.org/wiki/EPEL

[rckclmbr]

Then you have to use scl, which kind of sucks. Better to just install the fedora packages. Or compile it yourself (but you should really package it if you're deploying it on a lot of servers)

[drb91]

Meh, RHEL customers can look after themselves and maintain a python2 fork. Unless they’re paying you it makes sense to target the most recent version of the language.

[gigatexal]

I’m not an enterprise developer but does RHEL 7 support docker? Run python3 in a container. Isn’t that the point of containers?

[nudpiedo]

you mean bringing code which has not been cleared as secure & authorized by corporation's legal experts? BigCorp makes all those easy things hard (usually after lessons learnt).

[gigatexal]

Even if you run official builds by the python foundation from the library on docker hub? That seems like a business opportunity: certify software for RHEL by all the government bodies and pay RH for sign off and then be the only vendor to be sanctioned to run “third party but vetted” python3.

[rspeer]

If a group has a security policy that makes it hard for them to install Python 3, of course there's no way in hell they're installing Docker.

[gigatexal]

fair enough i didn't know these things; learned something new today.