[CentOS-devel] RHEL 8, and potentially CentOS 8, lack "/usr/bin/python"

On Sun, May 12, 2019 at 5:02 AM Phil Perry <pperry at elrepo.org> wrote:
>
> On 12/05/2019 04:45, Nico Kadel-Garcia wrote:
> > Good evening:
> >
> > Even though Fedora still has a default /usr/bin/python, which has
> > admittedly changed to a link to /usr/bin/python3 for recent releases,
> > I see that RHEL 8 has no /usr/bin/python. This is going to break a
> > *lot* SRPM's and older python scripts. It's especially going to mess
> > up old "__python" configuration macros for .spec files.
> >
> > I'd not realized this when I started testing. Heads up, a *lot* of
> > EPEL .spec files are going to need updates.
> >
>
> Correct, there is no default 'python' in RHEL8 - you have python2 and
> python3, and you get to decide which you wish to use. This is well
> documented and there have been a lot of RH articles and blog postings
> about it. See for example:
>
> https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8/

Right. There are many SRPMs in various repositories, especially EPEL
and Fedora, that explicitly use '%{__python}' or /usr/bin/python in
their .spec files, and many scripts that use "#!/usr/bin/env python".
They all have to be updated. Evaluating RHEL 8

And sorry if this makes me seem a bit lame, but I've only just started
testing RHEL 8 in force. I've not tried to catch up on all the blogs.

> If you are packaging software, you will need to decide if you wish to
> build against python2, python3 or both (that's going to be fun) and
> specify that explicitly. For example, we needed to patch the mock SPEC
> file when porting the latest version of mock from fedora to RHEL8 to
> explicitly specify python2 and/or python3.

Yeah, I took a shot at building mock before I was pointed to
https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8/, which
is very useful indeed. I also went through a lot of this when I
backported awscli to RHEL 6 over at
https://github.com/nkadel/awsclirepo . I was just noticing this on
RHEL 8 as I tried to port awscli.

I'm sad to say that there are was also a confusing decision to rename
some packages such as "platform-python-coverage" instead of the old
name "python3-coverage", matching the python2-coverage which still
exists. I've no idea why someone specifically chose to violate that
naming convention, and it had to be a conscious choice.

> The good news is the errors are pretty obvious:

Yeah, I've been running into this with RHEL 6 and CentOS 6 backports
and on Fedora 30 where /usr/bin/python points to /usr/bin/python3. The
errors are usually obvious, they just take time to fix and resolve. It
*does* make me encourage the us of both "with_python2" and
"with_python3" as options, so that which modules an SRPM is building
can be explicit and help us migrate python2 packages to python3 in
parallel, and safely.