Python dependency hell.

At the beginning there was the Bourne Shell. Then, Perl was created to better deal with character strings and regular expressions.

Linux came and the Bourne Shell was replaced with Bash (Bourne Again SHell) with many built-in features like integer arithmetic.

Because of its unusual syntax and its lack of object-oriented capabilities, Perl is now replaced with Python.

Today, Python is almost everywhere: tools like yum, tuned or Firewalld are all written in Python.

As the CPAN (Comprehensive Perl Archive Network) offered an incredible number of modules for Perl, Python modules have also been created to provide additional features.

They can be installed through RPM packages or with the pip install command.

Here is a potential problem. When you install a Python module through an RPM package, you get all the work done by the maintainer behind (RedHat, CentOS, EPEL, etc) to make sure that this module and all its dependencies will work fine together.

On the contrary, when you run the pip install command, you don’t know where the Python module will be installed and what exact dependency will be activated. In my experience, this doesn’t work very well. You can get the same Python module in different versions on the same server. In this situation, everything becomes very complicated. And this is not a RHEL/CentOS specific problem but concerns most of the Linux distributions.

Furthermore, the pip install method sometimes requests that you compile modules locally. To compile Python modules, you need to install the gcc compiler: this is not a good practice in a production environment.

Conclusion: If you are not an expert in Python, stay away from the pip install command. Get your qualified contractor now.