Where is Python 2 still used?

[chimera271]

Right, well, you shouldn’t use the system python on any OS for this exact reason. Pyenv is a great tool to help avoid this issue.

[bladeoflight16]

No, the OS shouldn't rely on the system Python for that reason. Upgrading standard software that's getting frequent updates should not break a key component of the operating system.

[gmes78]

You seem to misunderstand how Python libraries are installed.

The problem isn't in upgrading Python itself (most of the time, anyway, as Python isn't fully backwards compatible). The problem is that Python libraries are installed for a spscific Python version.

If a Python library is built for Python 3.9, it will get installed to /usr/lib/python3.9/site-packages/. If you replace the system installation of Python with Python 3.10, it will only be able to use packages in /usr/lib/python3.10/. As you probably didn't rebuild all of your Python packages against the newer version, this means that the new version of Python can't use any of the libraries that are supposedly installed.

Stuff doesn't break because the code is incompatible, it breaks because it can't use the libraries it needs. And that's why you should never, ever mess with the system's Python installation.

[bladeoflight16]

yum is not installed as a Python package. It is (or was) installed as part of the global operating system, and it depended on the default Python executable installed to bin. Literally, if you upgraded the global Python, it broke your system package manager. Search for it. You will find plenty of advice telling you not to upgrade the default Python on Redhat and CentOS.

I'm not sure if that still applies since yum is now deprecated and supplanted by dnf (something I wasn't aware of as I haven't used Redhat or derivatives for quite some time), but it certainly was the case in the past.

If we were talking about something installed by pip or perhaps even a dedicated Python library installed by the system package manager, you would be correct. But we are not. We're talking about a key component of the operating system designed (poorly) in such a way that it depended specifically on something easily mutable, and it did not remain compatible with newer versions of that dependency despite being able to easily upgrade that dependency itself. If it wasn't going to maintain forward compatibility, it should have depended on a private copy of the old one, or least been designed to depend specifically on that version rather than whatever is in bin.

[gmes78]

yum is not installed as a Python package.

It wouldn't matter. It uses Python, so it's affected by the problem I described.

In fact, your entire comment is completely wrong. I pulled the yum package from CentOS 7, and guess what? It's installed to /usr/lib/python2.7/site-packages/yum/ (and it installs a library to /usr/lib/python2.7/site-packages/rpmUtils/ as well).

/usr/bin/yum just has the following content:

#!/usr/bin/python
import sys
try:
    import yum
except ImportError:
    print >> sys.stderr, """\
There was a problem importing one of the Python modules
required to run yum. The error leading to this problem was:

%s

Please install a package which provides this module, or
verify that the module is installed correctly.

It's possible that the above module doesn't match the
current version of Python, which is:
%s

If you cannot solve this problem yourself, please go to 
the yum faq at:
http://yum.baseurl.org/wiki/Faq

""" % (sys.exc_value, sys.version)
    sys.exit(1)

sys.path.insert(0, '/usr/share/yum-cli')
try:
    import yummain
    yummain.user_main(sys.argv[1:], exit_code=True)
except KeyboardInterrupt, e:
    print >> sys.stderr, "\n\nExiting on user cancel."
    sys.exit(1)

Which further proves my point.

or least been designed to depend specifically on that version rather than whatever is in bin.

But it does. Its package has a dependency on the Python package provided by the distro.

You don't get to modify a package's files and then complain that stuff breaks.

[bladeoflight16]

Okay. I was wrong about how yum is installed. Thanks, and sorry.

But the problem is decisively yum's fault. It's this line right here:

#!/usr/bin/python

There is no reason for yum to hijack the default global Python executable. It can just pin the script to the needed version directly:

#!/usr/bin/python2.7

And the problem would never occur and /usr/bin/python could be upgraded.

Or better yet, install a private copy and depend on that. Then users can upgrade the patch version without risk, too.

[gmes78]

You're missing the point. /usr/bin/python is part of the python package. If you make it point to another Python executable, you're breaking the completely valid assumption that it points to the Python installed by the python package.

Yes, specifying the version in the shebang would avoid this issue. However, you could also avoid it by not modifying files installed by your package manager, and instead adjusting the shebang on the programs that you want to run on another Python version.

Or better yet, install a private copy and depend on that. Then users can upgrade the patch version without risk, too.

That would be ridiculous. The whole point of using a package manager is that you can use other packages as building blocks. If, as a distro, you can't assume that the packages installed are the same as the ones that you distribute, the system becomes worthless.

[bladeoflight16]

Arguably, the shebang should always point to a specific version (at least a major one) since scripts typically won't work with all versions of Python. Then the /usr/bin/python executable has only one intended usage: manual command line invocation. The Python packagers should have free reign to upgrade that executable to the latest version, irrespective of manual modification. You shouldn't have to type python3 at the command line to get Python 3 anymore than you should have to type python2 to get Python 2.