[throwaway98434]

You say "you" as if you're talking to the person you're replying to. Most scripts in the world aren't authored by the person you're replying to. They're powerless to change the ocean of python out in the world.

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.

[isostatic]

Of the 50 /usr/bin/ python files on my Ubuntu 16.04 desktop, most are versioned in some way. None are called from "env".

     37 /usr/bin/python3
      4 /usr/bin/python3.5
      4 /usr/bin/python
      3 /usr/bin/python2.7
      2 /usr/bin/python2

The 4 that aren't versioned are

speedtest, speedtest-cli, dh_python2, apt-offline

So two from ubuntu/debian, and two from a package

[throwaway98434]

Right, someone working in ubuntu distro development has done this work for those packages specifically.

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.

[isostatic]

You're discussing RHEL7's /usr/bin.

  > For example, out of about 50 or so /usr/bin/python scripts I see in a RHEL7's /usr/bin

I posted Ubuntu 1604's in comparison.

[throwaway98434]

I'm discussing the problem of collections of python scripts using /usr/bin/python and I included the state of RHEL7 as an example.

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.

[rterzi]

First, This is about RHEL 8 (Beta) not 7, 6, etc. Second `#!/usr/bin/python` is a different animal than `#!/usr/bin/env python`. One is hard coded. The other is `PATH` based so will change depending on current `PATH`.

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

[throwaway98434]

CoolGuySteve complained that things will break because existing scripts assume /usr/bin/python. CoolGuySteve is correct. There is an enormous amount of work involved in changing or removing the function of /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.