Red Hat Developers: How to install Python 3 on RHEL

This article shows how to install Python 3, pip, venv, virtualenv, and pipenv on Red Hat Enterprise Linux 7. After following the steps in this article, you should be in a good position to follow many Python guides and tutorials using RHEL.

Using Python virtual environments is a best practice to isolate project-specific dependencies and create reproducible environments. Other tips and FAQs for working with Python and software collections on RHEL 7 are also covered.

There are a number of different ways to get Python 3 installed on RHEL. This article uses Red Hat Software Collections because these give you a current Python installation that is built and supported by Red Hat. During development, support might not seem that important to you. However, support is important to those who have to deploy and operate the applications you write. To understand why this is important, consider what happens when your application is in production and a critical security vulnerability in a core library (for example SSL/TLS) is discovered. This type of scenario is why many enterprises use Red Hat.

Python 3.6 is used in this article. It was the most recent, stable release when this was written. However, you should be able to use these instructions for any of the versions of Python in Red Hat Software Collections including 2.7, 3.4, 3.5, and future collections such as 3.7.

In this article, the following topics are discussed:

TL;DR (summary of steps)
Full installation steps with explanations
How to use Python 3 through Red Hat Software Collections
Working with Python virtual environments
1. using venv
2. using virtualenv
3. Managing application dependencies using pipenv
General tips for working with Python
Tips for working with software collections
More information: Developing in Python on Red Hat Platforms
Troubleshooting

TL;DR

Here are the basic steps so you can just get going. See below for explanations and more details.

How to install Python 3 on RHEL

Become root.
Enable the rhscl and optional software repos using subscription-manager.
Use yum to install @development. This makes sure you’ve got GCC, make, git, etc. so you can build any modules that contain compiled code.
Use yum to install rh-python36.
Optional: Use yum to install python-tools, numpy, scipy, and six from RHSCL RPMs.

$ su -
# subscription-manager repos --enable rhel-7-server-optional-rpms \
  --enable rhel-server-rhscl-7-rpms
# yum -y install @development
# yum -y install rh-python36

# yum -y install rh-python36-numpy \
 rh-python36-scipy \ 
 rh-python36-python-tools \
 rh-python36-python-six

# exit

Using Python 3 on RHEL

Under your normal user ID, run scl enable to add python 3 to your path(s).
Create a Python virtual environment and activate it. (Note: your prompt has changed to show the virtual environment.)
Install whatever additional modules you need with pip in an isolated environment without being root.

$ scl enable rh-python36 bash
$ python3 -V
Python 3.6.3

$ python -V  # python now also points to Python3 
Python 3.6.3

$ mkdir ~/pydev
$ cd ~/pydev

$ python3 -m venv py36-venv
$ source py36-env/bin/activate

(py36-venv) $ python3 -m pip install ...some modules...

If you start a new session, here are the steps for using your virtual environment:

$ scl enable rh-python36 bash

$ cd ~/pydev
$ source py36-env/bin/activate

Why use Red Hat Software Collections

The benefit of using Red Hat Software Collections is that you can have multiple versions of Python installed at the same time along with the base Python 2.7 that shipped with RHEL 7. You can easily switch between versions with scl enable.

Note: The latest stable packages for .Net Core, Go, Rust, PHP 7, Ruby 2.5, GCC, Clang/LLVM, Nginx, MongoDB, MariaDB, PostgreSQL, and more are all yum– installable as software collections. So you should take the time to get comfortable with software collections.

Using software collections requires an extra step because you have to enable the collection you want to use. Enabling just adds the necessary paths (PATH, MANPATH, LD_LIBRARY_PATH) to your environment. Once you get the hang of it, software collections are fairly easy to use. It really helps to understand the way that environment-variable changes work in Linux/UNIX. Changes can be made only to the current process. When a child process is created, it inherits the environment of the parent. Any environment changes made in the parent after the child has been created will have no effect on the child. Therefore, the changes made by scl enable will affect only the current terminal session or anything started from it. This article also shows how you can permanently enable a software collection for your user account.

Installation Prerequisites

Install development tools including GCC, make, and git

If you install modules that depend on compiled code you’ll need the tools to compile them. If you haven’t already installed development tools run the following command:

$ su -
# yum install @development

Enable repos with additional developer tools

While the default/base RHEL software repos have many development tools, these are the older versions that are shipped with the OS and are supported for the full 10-year life of the OS. Packages that are updated more frequently and have a different support lifecycle are distributed in other repos that aren’t enabled by default.

Red Hat Software Collections are in the rhscl repo. RHSCL packages have some dependencies on packages in the optional-rpms repo, so you need to enable both.

To enable the additional repos, run the following commands as root:

$ su -
# subscription-manager repos \
 --enable rhel-7-server-optional-rpms \
 --enable rhel-server-rhscl-7-rpms

Notes:

You can enter the above all on one line without the backslashes. The backslashes are needed if you want to use multiple lines for readability.
If you are using the workstation variant of RHEL, change -server- to -workstation-.
This command needs to be run only once. The repos will stay enabled. All of the enabled repos will be searched by yum when installing or updating software.
The no-cost RHEL subscription for developers includes access to all of these repos and the server variant of RHEL. The server variant is a superset.
For more information, see the FAQ for the no-cost subscription.

To see which repos are available for your current subscription, run the following command:

# subscription-manager repos --list

To see which repos are enabled, use --list-enabled:

# subscription-manager repos --list-enabled

Install Python 3

You can now install Python 3.6 (or other versions in RHSCL) with yum:

# yum install rh-python36

Notes:

These packages will install in /opt/rh/.
They will not be added to your path until you run scl enable. See below.
For other versions of Python, use the following as the package/collection name:
Python 3.5: rh-python35
Python 3.4: rh-python34
Python 2.7.13: python27
A number of additional packages will be installed as dependencies. These include python-devel, pip, setuptools, and virtualenv.
The python-devel package contains the files needed if you have to build any modules that dynamically link into Python (such as C/C++ code).

Install additional packages

Optionally, you may want to install the following RPM packages that are part of the software collection:

Python tools: rh-python36-python-tools is a collection of tools included with Python 3, 2to3, and idle3.
Numpy: rh-python36-numpy is a fast multidimensional array facility for Python.
Scipy: rh-python36-scipy provides scientific tools for Python.
Six: rh-python36-python-six provides Python 2 and 3 compatible utilities.
Sqlalchemy: rh-python36-python-sqlalchemy is a modular and flexible ORM library for Python.
PyYAML: rh-python36-PyYAML is a YAML parser and emitter for Python.
Simplejson: rh-python36-python-simplejson is a simple, fast, extensible JSON encoder/decoder for Python.

Example:

# yum install rh-python36-numpy \
 rh-python36-scipy \ 
 rh-python36-python-tools \
 rh-python36-python-six

Note: By default system modules will not be used with Python virtual environments. Use the option --system-site-packages when creating the virtual environment to include system modules.

How to use Python 3 (`scl enable`)

Python 3 is now installed. You no longer need to run under the root user ID. The rest of the commands should be executed using your normal user account.

As previously mentioned, software collections are installed under /opt/rh and aren’t automatically added to your PATH, MANPATH, and LD_LIBRARY_PATH. The command scl enable will make the necessary changes and run a command. Because of the way environment variables work in Linux (and UNIX), the changes will take effect only for the command run by scl enable. You can use bash as the command to start an interactive session. This is one of the most common ways (but not the only way) of working with software collections.

$ scl enable rh-python36 bash
$ python3 -V
Python 3.6.3
 
$ python -V # python now points to Python 3
Python 3.6.3

$ which python
/opt/rh/rh-python36/root/usr/bin/python

Note: Enabling the Python collection makes the python in your path, with no version number, point to Python 3. /usr/bin/python will still be Python 2. You can still run Python 2 by typing python2, python2.7, or /usr/bin/python. It is recommended that you use a version number to avoid any ambiguity about what python means. This also applies to other Python commands in .../bin such as pip, pydoc, python-config, pyvenv, and virtualenv. For more information, see PEP 394.

NOTE: See How to permanently enable a software collection below to permanently put Python 3 in your path.

Create a Python virtual environment (best practice)

Using Python virtual environments is a best practice to isolate project-specific dependencies and create reproducible environments. In other words, it’s a way to avoid conflicting dependencies that lead to dependency hell. Using a virtual environment will let you use pip to install whatever modules you need for your project in an isolated directory under your normal user ID. You can easily have multiple projects with different dependencies. To work on a specific project, you activate the virtual environment, which adds the right directories to your path(s).

Using virtual environments along with pip list, pip freeze, and a requirements.txt file gives you a path to a reproducible environment to run your code it. Others that need to run your code can use the requirements.txt file you generate to create a matching environment.

By default, virtual environments will not use any system installed modules, or modules installed under your home directory. From an isolation perspective and for creating reproducible environments this is generally considered the correct behavior. However, you can change that by using the argument --system-site-packages.

Should I use `venv` or `virtualenv` or something else?

When you install Python 3 from Red Hat Software Collections, venv, virtualenv, and pip will be installed, so you are ready to install whatever modules you choose. “Installing Python Modules” in the current Python documentation says this:

venv is the standard tool for creating virtual environments, and has been part of Python since Python 3.3.
virtualenv is a third-party alternative (and predecessor) to venv. It allows virtual environments to be used on versions of Python prior to 3.4, which either don’t provide venv at all or aren’t able to automatically install pip into created environments.

So for all the recent versions of Python 3, venvis preferred.

If you work with Python 2.7, you’ll need to use virtualenv.

The commands to create the virtual environments differ only in the module name used. Once created, the command to activate the virtual environment is the same.

Note: for virtualenv, using python3.6 -m virtualenv is recommended instead of using the virtualenv command. See Avoid using Python wrapper scripts below for more information.

Create and activate a virtual environment with `venv`

If you haven’t already done so, enable the rh-python36 collection:

$ scl enable rh-python36 bash

Now create the virtual environment. To avoid any surprises, use an explicit version number for running Python:

$ python3.6 -m venv myproject1

Anytime you need to activate the virtual environment, run the following command.

$ source myproject1/bin/activate

Note: once you’ve activated a virtual environment, your prompt will change to remind you that you are working in a virtual environment. Example:

(myproject1) $

Note: When you log in again, or start a new session, you will need to activate the virtual environment using the source command again. Note: you should already have run scl enable before activating the virtual environment.

For more information, see Virtual Environments and Packages in the Python 3 tutorial at docs.python.org.

Create and activate a virtual environment with `virtualenv`

If you haven’t already done so, enable the rh-python36 collection:

$ scl enable rh-python36 bash

Now create the virtual environment. To avoid any surprises, use an explicit version number for running Python:

$ python3.6 -m virtualenv myproject1

Anytime you need to activate the virtual environment, run the following command. Note: you should already have run scl enable before activating the virtual environment.

$ source myproject1/bin/activate

Note: once you’ve activated a virtual environment, your prompt will change to remind you that you are working in a virtual environment. Example:

(myproject1) $

For more information, see Installing packages using pip and virtualenv in the Python Packaging User Guide.

Managing application dependencies with `pipenv`

From the Python Packaging User Guide tutorial, Managing Application Dependencies:

“Pipenv is a dependency manager for Python projects. If you’re familiar with Node.js’ npm or Ruby’s bundler, it is similar in spirit to those tools. While pip alone is often sufficient for personal use, Pipenv is recommended for collaborative projects as it’s a higher-level tool that simplifies dependency management for common use cases.”

With pipenv you no longer need to use pip and virtualenv separately. pipenv isn’t currently part of the standard Python 3 library or Red Hat Software Colleciton. You can install it using pip. (Note: see the recommendation below about not running pip install as root.) Since pipenv uses virtualenv to manage environments, you should install pipenvwithout having any virtual environment activated. However, don’t forget to enable the Python 3 software collection first.

$ scl enable rh-python36 bash # if you haven’t already done so
$ python3.6 -m pip install --user pipenv

Creating and using isolated environments with pipenv works a bit differently than venv or virtualenv. A virtual environment will automatically be created if no Pipfile exists in the current directory when you install the first package. However, it’s a good practice to explicitly create an environment with the specific version of Python you want to use.

$ scl enable rh-python36 bash # if you haven’t already done so 
$ mkdir -p ~/pydev/myproject2
$ cd ~/pydev/myproject2
$ pipenv --python 3.6
$ pipenv install requests

To activate a Pipenv environment, cd into that directory and run pipenv shell.

$ scl enable rh-python36 bash # if you haven’t already done so 
$ cd ~/pydev/myproject2
$ pipenv shell

Pipenv is similar to scl enable in that it doesn’t try to modify the current environment with source, instead it starts a new shell. To deactivate, exit the shell. You can also run a command in the pipenv environment by using pipenv run command.

For more information see:

Managing Application Dependencies in the Python Packaging User Guide
The documentation at Pipenv.org
Pipenv and Virtual Environments at The Hitchhiker’s Guide to Python website

General tips for working with Python

The `python` command: Avoid surprises by using a version number

To avoid surprises, don’t type python. Use an explicit version number in the command, such as python3.6 or python2.7.

At a minimum, always use python3 or python2. If you are reading this article, you’ve got more than one version of Python installed on your system. Depending on your path, you might get different versions. Activating and deactivating virtual environments, as well as enabling a software collection, changes your path, so it can be easy to be confused about what version you’ll get from typing python.

The same problem occurs with any of the Python utilities such as pip or pydoc. Using version numbers, for example, pip3.6, is recommended. At a minimum use the major version number: pip3. See the next section for a more robust alternative.

Use `which` to determine which Python version will be run

Use the which command to determine the full path that will be used when you type a command. This will help you understand which version of python is in your path first and will get run when you type python.

Examples:

$ which python  # before scl enable
/usr/bin/python
 
$ scl enable rh-python36 bash

$ which python
/opt/rh/rh-python36/root/usr/bin/python
 
$ source ~/pydev/myproject1/bin/activate
 
(myproject1) $ which python
~/pydev/myproject1/bin/python

Avoid Python wrapper scripts such as `virtualenv`: Use the module name

Some Python utilities are put in your path as a wrapper script in a .../bin directory. This is convenient because you can just type pip or virtualenv. Most Python utilities are actually just Python modules with wrapper scripts to start Python and run the code in the module.

The problem with wrapper scripts is the same ambiguity that happens when typing python. Which version of pip or virtualenv you will get when you type the command without a version number? For things to work correctly, there is the additional complication that the utility needs to match the version of Python you intend to be using. Some subtle (hard to diagnose) problems can occur if you wind up unintentionally mixing versions.

Note: There are several directories that wrapper scripts can reside in. Which version you get is dependent on your path, which changes when you enable software collections and/or activate virtual environments. Modules installed with pip --user put their wrapper scripts in ~/.local/bin, which can get obscured by activating the software collection or a virtual environment.

You can avoid the surprises from the path issues by running the module directly from a specific version of Python by using -m modulename. While this involves more typing, it is a much safer approach.

Recommendations:

Instead of pip, use python3.6 -m pip.
Instead of pyvenv, use python3.6 -m venv.
Instead of virtualenv, use python3.6 -m virtualenv.

Do not run `pip install` as root (or with `sudo`)

Running pip install as root either directly or by using sudo is a bad idea and will cause you problems at some point. Some of the problems that you may encounter are:

Conflicts between the RPM packages and pip installed packages. The conflicts will most likely show up when you need to install a fixed or upgraded package or module. The install might fail or, worse, you may wind up with a broken installation. It’s best to let yum be the exclusive manager of the files in the system directories.
Runtime environments that can’t be easily reproduced. It can be difficult to determine which modules were installed via an RPM package or via pip. When you want to run your Python code on another system, what needs to be installed? Does it need to be installed system-wide? Will you get the same version of the modules you tested your code under?
Upgrading modules to solve one dependency can break some other code. Unfortunately, there are many cases where code needs a specific version of a module and newer versions might be incompatible. Running pip install as root means all modules get installed in a system-wide directory, making it hard to determine which modules were installed for a specific application.

Using virtual environments will allow you to isolate the modules you install for each project from the modules that are part of the Python installation from Red Hat. Using virtual environments is considered a best practice to create isolated environments that provide the dependencies needed for a specific purpose. You don’t need to use --user when running pip in a virtual environment since it will default to installing in the virtual environment, which you should have write access to.

If you aren’t using virtual environments, or need a module/tool to be available outside of a virtual environments, use pip --user to install modules under your home directory.

In case you think this is overly dire, see this xkcd comic. Don’t forget to hover so you see the alt text.

Use virtual environments instead of `pip --user`

Some guides recommend using pip --user. While this is preferred over running pip as root, using virtual environments is much better practice for properly isolating the modules you need for a given project or set of projects. pip --user installs use ~/.local, which can be obscured by enabling software collections and/or activating virtual environments. For modules that install wrapper scripts in ~/.local/bin, this can cause a mismatch between the wrapper script and the module.

The exception to this advice is modules and tools that you need to use outside of virtual environments. The primary example is pipenv. You should use pip install --user pipenv to install pipenv. That way, you’ll have pipenv in your path without any virtual environments.

Don’t use the system Python for your own projects

The Python version installed in /usr/bin/python and /usr/bin/python2 is part of the operating system. RHEL was tested with a specific Python release (2.7.5) that will be maintained for the full ten-year supported life of the OS. Many of the built-in administration tools are actually written in Python. Trying to change the version of Python in /usr/bin might actually break some of the OS functionality.

At some point, you might want to run your code on a different version of the OS. That OS will likely have a different version of Python installed as /usr/bin/python, /usr/bin/python2, or even /usr/bin/python3. The code you write may have dependencies on a specific version that can be best managed through virtual environments and/or software collections.

The one exception to the above is if you are writing system administration tools. In that case, you should use the Python in /usr/bin because it has the correct modules and libraries installed for the APIs in the OS. Note: If you are writing system administration or management tools in Python, you might want to take a look at Ansible. Ansible is written in Python, uses Jinja2 for templating, and provides higher-level abstractions for many system tasks.

Tip: If you need to work with Python 2.7, install the python27 software collection. Follow the installation steps above but use python27 instead of rh-python36. You can enable both collections at the same time, so you’ll have both the newer python2.7 and python3.6 in your path. Note: the collection you enable last is the one that will be first in your path, which determines the version you get when you type a command like python or pip without an explicit version number.

Don’t change or overwrite `/usr/bin/python`, `/usr/bin/python2`, or `/usr/bin/python2.7`

As mentioned above, the system Python is part of Red Hat Enterprise Linux 7 and is used by critical system utilities such as yum. (Yes, yum is written in Python.) So overwriting the system Python is likely to break your system—badly. If you try to compile Python from source, do not do a make install (as root) without using a different prefix or it will overwrite /usr/bin/python.

Software collection tips

Enable the Python collection before the virtual environment

You should always enable the Python software collection before using any of Python virtual environment utilities to create or activate an environment. In order for things to work correctly, you need to have your desired version of Python in your path because it will be needed by the Python virtual environment. A number of problems, some of which are subtle, come up if you try to enable/activate in the wrong order.

Example for venv:

$ scl enable rh-python36 bash
$ python3.6 -m venv myproject1
$ source myproject1/bin/activate

When reactivating later in a new shell:

$ scl enable rh-python36 bash
$ source myproject1/bin/activate

Example for virtualenv:

$ scl enable rh-python36 bash
$ python3.6 -m virtualenv myproject1
$ source myproject1/bin/activate

When reactivating later in a new shell:

$ scl enable rh-python36 bash
$ source myproject1/bin/activate

How to permanently enable a software collection

To permanently add Python 3 to your path(s), you can add an scl_source command to the “dot files” for your specific user ID. The benefit of this approach is that the collection is already enabled at every login. If you are using a graphical desktop, everything that you start from the menu will already have the collection enabled.

There are a few caveats with this approach:

When you type python with no version number, you will get Python 3 instead of Python 2. You can still get Python 2 by typing python2 or python2.7. Using an explicit version number is strongly recommended.
The above applies to other Python commands that are in .../bin such as pip, pydoc, python-config, pyvenv, and virtualenv. Use a version number to avoid surprises.
There is noscl disablecommand. Everything is in environment variables, so you can work around it, but it would be a manual process. You can, however, enable a different software collection that will then take precedence over the collection in your profile.

Using your preferred text editor, add the following line to your ~/.bashrc:

# Add RHSCL Python 3 to my login environment
source scl_source enable rh-python36

Note: you could also add the scl_source line to the start of a build script to select the desired Python for the build. If your build script isn’t written as a shell/bash script, you could just wrap it in a shell script that has the source scl_source command and then runs your build script.

How to use Python 3 from RHSCL in the #! (shebang) line of a script

You can create a script that will use Python from the software collection without a requirement for scl enable to be manually run first. This can be done by using /usr/bin/scl enable as the interpreter for the script:

#!/usr/bin/scl enable rh-python36 -- python3
import sys

version = "Python %d.%d" % (sys.version_info.major, sys.version_info.minor)
print("You are running Python",version)

Note: You may be tempted to try using just the full path to .../root/usr/bin/python without the scl enable. In many cases, this won’t work. The behavior is dependent on the specific software collection. For most collections, this will fail with a shared library error, since LD_LIBRARY_PATH isn’t set correctly. The python27 collection doesn’t give an error, but it finds the wrong shared library, so you get the wrong version of Python, which can be surprising. However, rh-python36 can be referenced directly without setting LD_LIBRARY_PATH, but it is currently the only Python collection that works that way. There is no guarantee that future collections will work the same way.

How to see which software collections are installed

You can use the command scl -l to see what software collections are installed. This will show all software collections that are installed, whether they are enabled or not.

$ scl -l
python27
rh-python36

How to tell which software collections are enabled

The environment variable X_SCLS contains a list of the software collections that are currently enabled.

$ echo $X_SCLS
$ for scl in $X_SCLS; do echo $scl; done
rh-python36
python27

In scripts, you can use scl_enabled collection-name to test if a specific collection is enabled.

How can I find a list of Red Hat Software Collections and how long they are supported?

See Red Hat Software Collections Product Life Cycle on the Red Hat Customer Portal. It has a list of Red Hat Software Collections packages and support information.

You can also check the release notes for the most recent release of Red Hat Software Collections.

Find additional RPM packages and see other available versions

You can use yum search to search for additional packages and see the other versions that are available:

To search for other packages that are part of the rh-python36 collection:

# yum search rh-python36

Starting with the Python 3.4 collection, the collection and package names are all prefixed with rh-. So you can use the following command to see all of the rh-python packages and, therefore, see what collections are available.

# yum search rh-python

Note: to see the available packages in the Python 2.7 collection, search for python27.

# yum search python27

You can, of course, just search for python and get a list of every available RPM that has python in the name or description. It will be a very long list, so it’s best to redirect the output to a file and use grep or a text editor to search the file. The packages that start with python- (without a version number) are part of the base RHEL Python 2.7.5 packages that are installed in /usr/bin.

Troubleshooting

Python: error while loading shared libraries

This error occurs when you are trying to run a binary but the shared libraries it depends on can’t be found. Typically this occurs when trying to run python from a software collection without enabling it first. In addition to setting PATH, scl enable also sets LD_LIBRARY_PATH. This adds the directory containing the software collection’s shared objects to the library search path.

To see what environment variables are modified, take a look at /opt/rh/rh-python/enable.

$ cat /opt/rh/rh-python36/enable 
export PATH=/opt/rh/rh-python36/root/usr/bin${PATH:+:${PATH}}
export LD_LIBRARY_PATH=/opt/rh/rh-python36/root/usr/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
export MANPATH=/opt/rh/rh-python36/root/usr/share/man:$MANPATH
export PKG_CONFIG_PATH=/opt/rh/rh-python36/root/usr/lib64/pkgconfig${PKG_CONFIG_PATH:+:${PKG_CONFIG_PATH}}
export XDG_DATA_DIRS="/opt/rh/rh-python36/root/usr/share:${XDG_DATA_DIRS:-/usr/local/share:/usr/share}"

Wrong version of Python when running `python`

First, running python with no version number is likely to give you an unexpected version of Python at some point. The result is dependent on your PATH, which depends on whether you’ve enabled the software collection and/or activated the virtual environment. If you use a version number such as python3.6 and you haven’t enabled/activated the right environment, you’ll get a clean and easy-to-understand “command not found” error.

Second, you can also get the wrong version if you’ve forgotten to enable the software collection. Enabling the software collection puts the collection’s /bin directory in your path first, so it will hide all of the other versions of commands with the same name.

The software collection needs to be enabled even if you give the full path to the python binary. For most of the collections, you’ll get a shared library error (see above) without the library path being set correctly. However, if you try this with the python27 collection, you’ll get Python 2.7.5 (the default version) instead of Python 2.7.13 as you’d expect. This is because the shared library dependency is satisfied out of /lib instead of from the software collection, so you pick up the system Python.

Error running `pip`: ImportError cannot import name ‘main’

If you run pip upgrade --user pip, as some guides suggest, the pip command will no longer work. The problem is a path issue combined with an incompatibility between versions. The user installation of pip placed a new pip command in ~/.local/bin. However, ~/.local/bin is in your path *after* the software collection. So you get the older wrapper script that is incompatible with the newer module.

This can be worked around in several ways:

Use virtual environments. Once you create or activate a virtual environment, you’ll get the correct pip wrapper script in the .../bin directory of the virtual environment.
Run pip as a module: python3.6 -m pip install … (See “Avoid Python wrapper scripts” above.)
Don’t upgrade pip outside of virtual environments.
Use the full path to the pip wrapper script: ~/.local/bin/pip3.6.
Add ~/.local/bin as the first directory in your PATH after enabling the Python software collection.

Note: To uninstall the upgraded pip that was installed in ~/.local, run the following command under your regular user ID (not root):

$ python3.6 -m pip uninstall pip

Can’t find `virtualenv3.6`

The rh-python36 software collection includes the virtualenv wrapper script but does not have a link for virtualenv3.6. There are two workarounds for this, but first I should point out that venv is now the Python 3 preferred tool for virtual environments.

The preferred workaround is to avoid the wrapper script entirely and invoke the module directly:

$ python3.6 -m virtualenv myproject1

Alternatively, you could create your own symlink in your ~/bin directory:

$ ln -s /opt/rh/rh-python36/root/usr/bin/virtualenv ~/bin/virtualenv3.6

More information: Developing in Python on Red Hat Platforms

Nick Coghlan and Graham Dumpleton gave a talk Developing in Python on Red Hat Platforms at DevNation 2016. The talk is chock full of information and still very relevant. They include information on building Python applications using containers, using s2i, and deploying to Red Hat OpenShift. I recommend watching the video or at least reviewing the slides.

Summary

After reading this article you’ve learned:

How to install Python 3 and other versions of Python that are supported by Red Hat using Red Hat Software Collections on Red Hat Enterprise Linux
Python virtual environments are a best practice for installing Python modules while isolating dependencies in order to avoid conflicts. You can create and activate virtual environments with venv and virtualenv. Both tools will be installed for you as part of the software collection.
About pipenv, a tool that is similar to npm, which is recommended by the Python Packaging Guide for managing application dependencies, especially on shared projects. Pipenv provides one command that integrates both pip and virtualenv.
Things to avoid such as:
- Running pip install as root to avoid conflicts with the RPM packages installed by yum
- Typing python without a version number to avoid ambiguity about which version will be run and surprises that might result from that
- Modifying /usr/bin/python since many system management tools such as yum depend on it and might break
Tips for working with Red Hat Software Collections
- Always enable the Python software collection before using virtual environments
- How to permanently enable a software collection, so you’ll always have python3 in your path
- How to use Python 3 from RHSCL in the #! (shebang) line of a script
How to troubleshoot common problems such as
- Python: error while loading shared libraries
- pip upgrade breaks pip with: ImportError cannot import name ‘main’
- Wrong version of Python when typing python

Image may be NSFW.
Clik here to view.

The post How to install Python 3 on RHEL appeared first on RHD Blog.