What, No Python in RHEL 8 Beta?
developers.redhat.com
developers.redhat.com
This was a good move.
> we came to the tough conclusion, don’t provide a default, unversioned Python at all. Ideally, people will get used to explicitly typing python3 or python2.
This seems like a principled stance, one I can agree with. But it's probably one RHEL will suffer for. I think they have a lot of share for the enterprise linux marketplace (maybe #1 or #2?), so maybe they can afford it. RHEL customers should dust off their Python2 source and seriously consider migrating to straddle both 2 and 3 for now. Although the fact that RHEL8 provides ten years of Python 2 support means that they're unlikely to feel that pressure any time soon.
This approach is a fair one, which will keep all their customers happy. If you've got complex Python 2 applications deployed on CentOS 7, then this won't be a hindrance to migration. Likewise if you want to drop Python 2 and only deploy with Python 3, they have that covered as well.
All in all, it sounds pragmatic and reasonable, and from the business point of view, they aren't going to lose customers as a result, by having huge blockers to upgrading.
Customers will do what they want to do with Python 2.7 code and libraries that work very well right now. The continuous improvement workers are clearly annoyed that Python 2.7 is not broken.
With the right amount of effort, Python 2.7 will continue to work well for the next ten years.
Perl comes to mind here..
Earlier this year, one of the projects I maintained started failing on CentOS 6 (Python 2.6). No code changes had been made to account for it. What had happened was that pip/pypi had updated some modules which had dropped Python 2.6 support, and now required Python 2.7. Unfortunately, the package management and dependency information is so rudimentary that pip will happily create an environment which is completely broken, or fails to build due to the scripts being incapable of running with an older interpreter. This completely broke our build.
The same fate lies in wait for Python 2.7. A number of common modules are planning on fully dropping Python 2.7 support come the EOL date. Once they do so, pip will break, and it will not be possible to construct a working environment except by hand. Or using manually packaged modules e.g. from the FreeBSD ports tree or the Debian archive. This will be the death knell for Python 2.7 for practical use and deployment. It will only take a tiny number of critical modules to make the switch for the whole pip/pypi ecosystem to be completely crippled for use with Python 2.7.
Or by explicitly specifying versions in requirements.txt (yes, it can be pita for dependencies inherited from other packages). Pypi does keep the old versions, no need to scour fbsd or debian archives.
That on its own would be somewhat manageable. But if you start getting requirements to update "just one more module" for some specific functionality, you eventually end up at the point where it's not possible to provision a functional set of modules. That's where I ended up with 2.6, and 2.7 is likely to be just the same, in my opinion.
New development, on the other hand, will be difficult. As it usually is, when you develop in something that has been obsoleted years ago. If you are still developing the system, instead of just keeping it running, shouldn't you spend some resources on python3 migration, too? The modules you need are already there.
The times we have had to update things have been when the existing modules broke. One example which comes to mind from the recent past is when urllib TLS certificate stuff broke and it needed updating. In that case, it didn't cause collateral damage, but we were forced to do it to keep things working. Externally-enforced changes like this could potentially cause breakage in the future if they drop python 2.7 support directly or indirectly.
If they are gonna do the work to support 3, just abandon 2.
Libraries are a different story.
I'm not saying this is a good way of doing things, simply that it's the practical reality for many codebases. And with tools like python-modernise, it's also eminently achievable. I've managed to do this with several Python codebases, so that they work with either 2 or 3, and in the future we can drop 2 and fully migrate to 3-only features. This allows a smooth, seamless transition with no breakage.
It would definitely be easier if a clean break could be made, and Python 2 support is dropped on the floor, but for many projects this is simply unacceptable.
I'm not convinced the attention is focused on "the experience".
Returning 404 is hardly a user friendly experience, even if the linked blog post (and thus the solution) is trivially Googleable. Maybe an error/informational message with instructions to `yum install python3` or `yum install python2` could be displayed instead?
The rule of (sore) thumb is: never use system Python for anything. Pretend it does not exist (and RH just did). It's there for running system software that happens to use Python interpreter and packages. It should only be managed by the system package / dependency manager.
For anything you write or download as source, explicitly install the right Python version, and create a separate virtualenv / container / whatnot, without any link to system-provided Python packages. It will save you a huge amount of headache.
I think the, let's be explicit about what we're installing approach isn't bad.
It also works for python2. I try to avoid using python tools that installs their own scripts and go for calling the module through python. This also works for python3/2 -m venv venv
For RHEL 8, the tools included with the system will use a different binary, platform-python that isn't in /usr/bin.
I can't remember if that's also the case for F28/F29.
(FWIW, I don't think either is installed by default, but maybe that was something else I installed recently?)
^ Needs verification
It's far from the first time in 18 years a package name has changed with a major version upgrade.
Now in order to support RHEL 8, you have to tell them to also have their sys admin install your preferred python.
A better and less bespoke to RHEL solution imo would have been to make an anaconda install or virtualenv the default python for each user.
Sigh.
For example, out of about 50 or so /usr/bin/python scripts I see in a RHEL7's /usr/bin I can't find a single one that runs on python3.
No individual user is going to be fixing this. It's a very silly and shortsighted move on RedHat's part.
37 /usr/bin/python3
4 /usr/bin/python3.5
4 /usr/bin/python
3 /usr/bin/python2.7
2 /usr/bin/python2
speedtest, speedtest-cli, dh_python2, apt-offline
So two from ubuntu/debian, and two from a package
Above, we're discussing some build system where someone hasn't done this work. Most collections of python code in the world (I'm going to hazard a guess significantly upward of 90%) just use /usr/bin/python or /usr/bin/env python.
That's the nature of the problem.
> For example, out of about 50 or so /usr/bin/python scripts I see in a RHEL7's /usr/bin
The actual subject is CoolGuySteve's build system, which is likely to look like my example of RHEL7 rather than yours of ubuntu. The vast majority of environments look like RHEL7 or CoolGuySteve's build system where #!/usr/bin/python is the norm.
On RHEL 7 (and earlier) `/usr/bin/python` must be the Python 2 the system shipped with or your break `yum` and other admin tools. When people try to install their own python by doing a `make install` as root, `yum` breaks and it's hard to recover the system.
What the article is saying is that RHEL 8 addresses this by having a platform python that the system tools use. So RHEL 8 tools will not use /usr/bin/python
Offering advice about how to write new software does nothing to help with the frustration he highlighted: His existing build systems will break. Build systems are especially frustrating as they tend to have hacked-together code that no one really wants to look at.
People will often work around this by installing a python2 as /usr/bin/python. At the end of the day this change results in a less predictable platform. On previous RHEL systems I know what /usr/bin/foo is -- it's predictable given the major version of the distro. But now I won't know what /usr/bin/python is on RHEL8. It will be uniquely different and that's not a good thing.
One interesting note - MacOS doesn't have a /usr/bin/python2 (at least, not at the time of this writing). It supplies /usr/bin/python, and also /usr/bin/python2.7.
That might not matter at all, but it's worth noting.
Similarly, if you require pandas like I do, there's a fairly comprehensive baseline of functionality you can expect regardless of what environment it comes from.
Also, FFS, why can’t pyc files have a bytecode format version number embedded in them, or at least be called .pyc3 by python 3?
The whole ecosystem needs to solve the packaging problem, or get replaced by some other language ASAP. Instead, it’s breaking entire distros with its packaging tire fire.
For many python projects I’ve dealt with, it is easier to reimplement that dang thing in some other language than make the python build reliable, secure and redistributable.
With C++ for example you are usually either targeting C++11, C++14, or C++17 (or if you're really unfortunate, C++03). The set of features in the language only changes every few years.
Granted it's still possible that someone could have an old compiler that doesn't implement the advertised standard correctly, but that's a bug, not a deliberate design choice.
And if you are talking about which version is shipped with a distro, then RHEL7 ships with gcc 4.8, which support only parts of c++14, while for example the latest Ubuntu LTS ships GCC 7,3, meaning you get full C++17 support.
Don't get me wrong, the Python packaging situation is not very clean. But it is far from being an exception, and people complaining about it are just spreading FUD.
This argument is almost cyclical.
> With C++ for example you are usually either targeting C++11, C++14, or C++17 (or if you're really unfortunate, C++03). The set of features in the language only changes every few years.
C++ went from glacial-pace changes - 85 / 98 / 03 / 11 -- to much faster ones: 14, 17, 20. This change in standards behavior was motivated by closing the gap with feature-rich, faster-moving languages like Python (Java, C#, etc).
Python makes language changes somewhat rarely, but library changes more often. The majority of the time, those library changes are brand new functionality.