Using Red Hat Software Collections

Red Hat Enterprise Linux (RHEL) is a very stable Linux distribution, widely used in industry, business, and education. It serves as the basis for a number of other Linux versions such as CentOS, Scientific Linux, Oracle Linux, etc. However, REHL generally prioritizes stability and reliability over having the latest versions of software available.

Since many users require versions of certain software (especially programming tools such as compilers) that are newer than what is available with RHEL 7 (and to a limited extent with RHEL 8 and RHEL 9), Red Hat created a mechanism called Software Collections. See the links below for much more information on Software Collections:

• Red Hat Software Collections Overview
• Linux Desktops Software Collections Guide
• Software Collections Home Page
  • Software Collections Guide
    This is a very useful, concise guide on how to use Software Collections.

You may also want to read the system manual page for the scl command with man scl. There are other, more advanced ways to use Software Collections than what is described in this overview. The above guides should help you make the most of them.

To check which specific software collections are available on a computer, use the scl -l (RHEL 7) or scl list-collections (RHEL 8/9) command:

user:hydra9 ~> scl -l
devtoolset-3
devtoolset-6
devtoolset-7
devtoolset-8
httpd24
python33
rh-git218
rh-java-common
rh-nodejs8
rh-php56
rh-python36

Most software collection names are fairly self-explanatory. However, if you are unsure what is included in each software collection, you can use the SoftwareCollections.org Search site to find out more. Simply enter the name of the software collection into the search to get more information, for example, rh-git123.

The scl command is also used to “enable” a software collection. By running scl enable <collection name> <shell> you can start a new shell where the software contained in the collection is now the default.

RHEL 7 ships with a very stable but old version of Python, 2.7.5. You can check the currently default Python version with the python –version command:

user:hydra9 ~> python --version
Python 2.7.5

To see which specific binary file is executed when you're running the python command, use which:

user:hydra9 ~> which python
/usr/bin/python

As you can see, Python is executed from the default system binary location of /usr/bin.
For your project, you will need to use Python version 3.3 instead of 2.7.5 and thus you will want to enable the “python33” software collection. By using the scl enable command you can start a new shell environment with the specific Software Collection “loaded” in by default. This is done, behind the scenes, by modifying certain environment variables such as the PATH variable. Run scl enable python33 zsh to start a new Z-Shell with Python 3.3 as the default version:

user:hydra9 ~> scl enable python33 zsh
user:hydra9 ~> python --version
Python 3.3.2
user:hydra9 ~> which python
/opt/rh/python33/root/usr/bin/python

In this example, you now have a Z-Shell with Python 3.3.2 as the default version of Python, run from a location other than the default system binaries. Other environment variables were also changed by the SCL command, for example the PYTHONPATH variable:

miturria:hydra9 ~> echo $PYTHONPATH
/opt/eecs/python33/lib/python3.3/site-packages:/opt/eecs/python33/lib64/python3.3/site-packages

Once you terminate your new shell (e.g. by typing exit) your settings will return to the default.

The above example shows how to create an interactive shell with a Software Collection enabled. However, in some cases you may want to run a script that uses a binary from a Software Collection such as a newer version of Python. There are several ways you can accomplish this. Let's assume you have a simple Python script called ver.py' that prints out the version of Python it is running under:

import sys
print("Python version")
print (sys.version)
print("Version info.")
print (sys.version_info)

Change the “shebang” (#!) of your script to load python but not from a specific location but using the default version. For example, if you normally put #!/usr/bin/python into your scripts, change this to #!/usr/bin/env python:

miturria:hydra9 ~> head -n1 ver.py
#!/usr/bin/env python
user:hydra9 ~> ./ver.py
Python version
2.7.5 (default, Jun 11 2019, 14:33:56)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)]
Version info.
sys.version_info(major=2, minor=7, micro=5, releaselevel='final', serial=0)


useer:hydra9 ~> scl enable python33 zsh
useer:hydra9 ~> ./ver.py
Python version
3.3.2 (default, Aug  5 2016, 06:28:52)
[GCC 4.8.3 20140911 (Red Hat 4.8.3-9)]
Version info.
sys.version_info(major=3, minor=3, micro=2, releaselevel='final', serial=0)

The head -n1 command shows you just the first line of the ver.py script. As you can see, before enabling the Software Collection, the script ran under Python 2 whereas after enabling, it ran under Python 3, all without having to change the script header.

If your script should always be run under Python 3, even when called from a shell that does not currently have Python 3 enabled, you can use an directly call the scl command inside your script. In our example, we can place the following line in our script header

#!/usr/bin/scl enable python33 -- python

This calls the scl command but instead of executing a shell, it will execute the python command directly. For example:

user:hydra9 ~> python --version
Python 2.7.5
user:hydra9 ~> ./ver.py
Python version
3.3.2 (default, Aug  5 2016, 06:28:52)
[GCC 4.8.3 20140911 (Red Hat 4.8.3-9)]
Version info.
sys.version_info(major=3, minor=3, micro=2, releaselevel='final', serial=0)

Note that even though the Software Collection was not loaded in the current shell, the script executed with Python 3 and not 2.