
What, No Python in RHEL 8 Beta? - collinmanderson
https://developers.redhat.com/blog/2018/11/27/what-no-python-in-rhel-8-beta/
======
wyldfire
> In order to improve the experience for RHEL 8 users, we have moved the
> Python used by the system “off to the side”

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.

~~~
mistrial9
> customers should dust off their Python2 source

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..

~~~
rleigh
It's going to break horribly in 2020 irrespective of RedHat's efforts.

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.

~~~
vetinari
> 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.

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.

~~~
rleigh
Yes, you're absolutely right about requirements.txt. However as you say, it's
a problem when you have to start considering transitive dependencies. In fact,
for the case I mentioned, this became a problem because there were so many it
became increasingly complex; you ended up having to start moving more and more
of the transitive dependencies directly into the requirements file. And this
isn't very scalable.

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.

~~~
vetinari
Transitive dependencies (or what I called inherited from other packages) can
be solved with pip freeze in existing working environment; it will list them
too.

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.

~~~
rleigh
No disagreement here from me!

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.

------
swalsh
I recently installed OpenSuse tubleweed. I'm not sure if I just had a weird
installation, but both python 2.7, and python 3.6 were installed. That's
great, but the "pip" command by default was pointed at pip3.6. Imagine how
confused I was when I installed a bunch of packages using the "pip" command,
but none of them were available from the default "python" shell.

I think the, let's be explicit about what we're installing approach isn't bad.

~~~
nitroll
python3 -m pip install foo

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

------
dade_
Great move. I recently experienced the whole Ubuntu 16.04 LTS Python 3.5 and
3.6 on my system and it is just plain messy. Yeah, they can co-exist, but now
I have 3 versions of Python. How many people didn't know better and have have
tried removing 3.5 and completely broke their install and possibly ruined
their weekend or evening. It also sends a message. A proper / official way for
distributions to deal with this situation is needed.

------
nailer
Any current Fedora users want to tell me what all the Red Hat tools use? Eg is
usr bin banana actually Python 2 or Python 3?

~~~
jlgaddis
Red Hat-specific tools or just all the general system utilities nstalled on a
RHEL host? I've got a ThinkPad sitting here running the beta of RHEL 8.

(FWIW, I don't think _either_ is installed by default, but maybe that was
something else I installed recently?)

~~~
mroche
Neither ship by default. If you run a search for libpython you should find one
hidden away in a nonstandard location. As far as I’m aware, only core tools
necessary for a minimal install rely on it. Other packages in the repos can
depend on an actual user space python version.

^ Needs verification

------
zenlot
"However, we do try to make it as easy as possible to get Python 2 or 3 (or
both) on to your system." \- it just requires quite a long blog post to
explain how easy it is.

~~~
sli
Install instructions are right at the top and are typical `yum` commands that
RHEL users should already know.

~~~
zenlot
So RHEL been around for 18 years, and suddendly users need to be aware about
the "install instructions", which "are right at the top" and read a blog post
about it for RHEL 8?

~~~
zamadatix
Presumably with RHEL being around for 18 years users would be able to run "yum
search python", see the packages are versioned, and yum install the version
they want. All sans blog article.

It's far from the first time in 18 years a package name has changed with a
major version upgrade.

------
PaulHoule
Woo hoo!

------
CoolGuySteve
This is such a strange and annoying compromise to make. It's somewhat
antithetical to the concept of RHEL versions being a standardized set of
packages such that when someone says "I have RHEL 7", you can say "My software
will work on that".

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.

~~~
mavhc
Wouldn't you just specify the dependencies in your installer so it just works?

~~~
CoolGuySteve
Most people in my field don't use installers or rpms, we just share the git
repo directly. I'm kind of pissed off just thinking about how many build
systems will break when '/usr/bin/env python' doesn't return anything by
default.

~~~
hedora
I’m pissed almost daily at how many build systems break because they need
3.5.3 vs 3.5.4 or whatever, and at how many only work because they create a
new virtual environment for every single script (Virtual environment ~= copy
of python auto-downloaded from some random places).

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.

~~~
umanwizard
Maybe Python should stop changing so often?

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.

~~~
antoinealb
Thats not really fair. Python 3.2 was release in 2011 and Python 3.4 in 2014.
Only 3.3 was released in the middle, I would not say it is only "so often"
compared to c++. To be more general, C++ had 3 major versions from 2011 to
2017, while python had 5. Its more, but not significantly so (especially since
very little compatibility is broken between 3.4 and 3.5 for example).

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.

~~~
StillBored
But the compiler is the same, so you specify the dialect you expect to use
rather than running a different binary. Although to be fair, at least one
distro decided to start shipping gcc like gcc-X where X is the version, so you
can have multiple GCC's installed. I'm not sure that was the best idea, but
its what they did.

