Ten years ago, the developers of the Python programming language decided to clean things up and release a backwards-incompatible version, Python 3. They initially underestimated the impact of the changes, and the popularity of the language. Still, in the last decade, the vast majority of community projects has migrated to the new version, and major projects are now dropping support for Python 2.
In Red Hat Enterprise Linux 8, Python 3.6 is the default. But Python 2 remains available in RHEL 8.
Using Python in RHEL 8
To install Python, type yum install python3
.
To run Python, type python3
.
If that doesn't work for you, or you need more details, read on!
Python 3
In RHEL 8, Python 3.6 is the default, fully supported version of Python. It is not always installed, however. Similarly to any other available tool, use yum install python3
to get it.
Add-on package names generally have the python3
prefix. Use yum install python3-requests
to install the popular library for making HTTP connections.
Python 2
Not all existing software is ready to run on Python 3. And that’s OK! RHEL 8 still contains the Python 2 stack, which can be installed in parallel with Python 3. Get it using yum install python2
, and run with python2
.
Why not just “Python”?
Okay, okay, so there's python3
and python2
. But what if I use just python
? Well…
$ python
-bash: python: command not found
There is no python
command by default.
Why? Frankly, we couldn’t agree what python
should do. There are two groups of developers. One expects python
to mean Python 2, and the other Python 3. The two don't always talk to each other, so you might be a member of one camp and not know anyone from the other – but they do exist.
Today, in 2018, the python == python2
side is more popular, even among those that prefer Python 3 (which they spell out as python3
). This side is also backed by an official upstream recommendation, PEP 394. However, we expect that this viewpoint will become much less popular over the lifespan of RHEL 8. By making python
always mean Python 2, Red Hat would be painting itself into a corner.
Unversioned Python command
That said, there are applications that expect a python
command to exist and that assumption might be hard to change. That’s why you can use the alternatives mechanism to enable the unversioned python
command system-wide, and set it to a specific version:
alternatives --set python /usr/bin/python3
For Python 2, use /usr/bin/python2
instead. For details on how to revert the changes or do the setup interactively, see man unversioned-python
.
Note, We do not recommend this approach. We recommend you explicitly refer to python3
or python2
. That way, your scripts and commands will work on any machine that has the right version of Python installed.
Note that this works only for the python
command itself. Packages and other commands don't have configurable unversioned variants. Even if you configure python
, the commands yum install python-requests
or pip
won't work.
Always use the explicit version in these cases. Better yet, don't rely on the wrapper scripts for pip
, venv
and other Python modules that you call from the command line. Instead use python3 -m pip
, python3 -m venv
, python2 -m virtualenv
.
Third-party packages
Not all Python software is shipped with RHEL 8 – there's only so much that Red Hat can verify, package and support.
To install a third-party package, many sources on the Internet will suggest using sudo pip install
. Do not do this! This command translates to “download a package from the internet, and run it on my machine as root to install it”.
Even if the package is trustworthy, this is a bad idea. A large part of RHEL 8 relies on Python 3.6. If you throw in another package, there's no guarantee that it will co-exist peacefully with the rest of the system. There are some protections in place, but you should generally assume that sudo pip
will break your system.
(Not to mention it won’t work as-is: the command name is pip3
or pip2
.)
If you want to use third-party packages, create a virtual environment using python3 -m venv --system-site-packages myenv
(or for Python 2, install python2-virtualenv
and run python2 -m virtualenv --system-site-packages myenv
). Then, activate the environment using source myenv/bin/activate
, and install packages into it using pip install
. The packages will then be available as long as the environment is activated. While this does not protect you against malicious packages, it does protect the system from unexpected breakage.
When a virtual environment is active, unversioned commands like python
and pip
will refer to the Python version that created the virtual environment. So, to install the Requests package, run pip install requests
(or if you prefer being explicit, python -m pip install requests
).
The --system-site-packages
switch makes the environment re-use libraries installed system-wide. Leave it out to get an isolated environment, where all libraries outside Python's standard library need to be installed explicitly.
Another possibility is installing user-specific packages with pip’s --user
switch. The command python3 -m pip install --user flake8
will make the flake8
linter available to you personally, leaving system tools like yum
unaffected.
If you truly need something installed system-wide, build a RPM package and use yum install
.
Obligatory note: Third-party packages installed with pip
are not reviewed or supported by Red Hat.
Platform-Python: The Python behind the curtain
Careful readers might have noticed a discrepancy here: Python is not installed by default, but yum
is, and yum
is written in Python. What magic makes that possible?
It turns out there is an internal Python interpreter called “Platform-Python”. This is what system tools use. It only includes the parts of Python needed for the system to function, and there are no guarantees that any particular feature won't be removed from it in the future.
However, libraries for Platform-Python are shared with the “user-visible” Python 3.6. This conserves disk space, and it also means that, for example, yum
extensions built for Python 3.6 will work for the system tool.
If you are not re-building the distro, do not use Platform-Python directly. Install python3
and use that.
Porting to Python 3
It won’t be in RHEL 8, but there will come a day when support for Python 2 will end. If you maintain Python 2 code, you should think about porting it to Python 3.
Python 3 was first released in 2008. For over a decade, it has been improving in features, performance and – ironically – compatibility with Python 2. You might have heard horror stories and urban legends about porting code to Python 3.0 or 3.2 that would be much less scary nowadays.
I’m not saying porting is trivial now, but it’s definitely gotten easier. As with any other change to a system, porting to Python 3 mainly requires knowledge of your codebase, good tests – and some time.
What’s the reward? Python 3 is a better language – after all, it's the language Python 2 developers choose to use! For enterprise applications, the main feature is reduced risk of hard-to-debug, input-dependent bugs when handling non-ASCII text such as people’s names (or emoji).
There are many community resources that document and help with porting to Python 3.
If you are reading this blog, you are probably working on a large, conservative code base. We ported a few of those, and distilled our experience in the the Conservative Porting Guide, a hands-on walkthrough that focuses on compatibility and keeping working code throughout the porting process. Give it a try, and if you find that something is not covered, let us know – or even send a pull request to it!
If you maintain Python C extensions, a similarly focused guide is part of the py3c project.
Takeaways
To install or run Python on RHEL 8, use python3
– unless you have a different version in mind.
Do not use sudo pip
.
Do not use platform-python for your applications. However, use platform-python if you are writing system/admin code for RHEL 8.
And if you have some code for Python 2, now is a great time to start modernizing it.
Enjoy Python in RHEL 8!
Last updated: February 22, 2024