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
If that doesn't work for you, or you need more details, read on!
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.
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
Why not just “Python”?
Okay, okay, so there's
python2. But what if I use just
$ 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
Note, We do not recommend this approach. We recommend you explicitly refer to
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
venv and other Python modules that you call from the command line. Instead use
python3 -m pip,
python3 -m venv,
python2 -m virtualenv.
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
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
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).
--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
If you truly need something installed system-wide, build a RPM package and use
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.
To install or run Python on RHEL 8, use
python3 – unless you have a different version in mind.
Do not use
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: May 7, 2019