Upgrading Python

Home » CentOS » Upgrading Python
CentOS 23 Comments

I am running CentOS 7 and I have python version:

Python 2.7.5 (default, Sep 15 2016, 22:37:39)

I need a newer version of 2.7 to pick up a bug fix. How can I do that
(without breaking anything in CentOS)?

23 thoughts on - Upgrading Python

  • I am not familiar with that. This is for a django app, using nginx, uWSGI, and mysql – will it integrate easily with those components?

  • Anaconda is a python installation independent of the OS. You can install it without root rights. Only your environment has to change to use the new python version

    I think is easy to

  • I’ve happily been using python virtual environments (similar to anaconda) alongside with Apache, WSGI & django for a long time. The setup using NGINX should be almost the same (with some small differences in setting up NGINX, of course).

    I would suggest “virtualenv” instead of anaconda: The principle is the same, but it offers just a bit more flexibility and customization. Virtualenv creates a local (non-system) installation of python, and you can create different collections of packages stored as different environments. In this way you can have multiple versions of python +
    different collections of packages all living happily side by side on the same machine.

    Regarding the setup with uWSGI + NGINX, the Django documentation “How to use Django with Apache and mod_wsgi”

  • This is a very mature app that we have deployed in many sites. The older sites run CentOS 6 and use apache and modwsgi. The newer sites run CentOS 7 and use nginx and uWSGI. So we am very familiar with their respective setups. But I have never used anything other then the out of the box python that came with the OS. So I am not sure how to get that nor if it will break anything. I am going to investigate Pete Biggs’ suggestion to use Software Collections.

  • Thanks. Missed that. Now I do get 7.5.13 but it seems I have to type that command in each new shell. Can I make that the default python? I
    want django and uWSGI to use that version.

  • The “default” python is a dependency for many other system packages, so changing it without understanding what effect it will have on other parts of the system would be dangerous. The idea behind Software Collections is that you only affect the packages that truly need the newer version.

    How are you launching django and uWSGI? I’d suggest putting the SC
    command in their startup scripts to keep the new version confined to them.

  • You likely can not make it the default python .. because all the system based things will likely break.

    However, you CAN add (call) the correct environment to your startup scripts for the proper deamons in init, which should run the required servers with the version of python that you want.

    The whole purpose of SCLs is to allow multiple versions of the same items to run together on a given machine, and you can pick the one you need for a give application/server service .. WHILE, not breaking 9in the case of python) things like yum :).

  • I believe doing something like

    source scl_source enable python27

    in .bashrc will do that. But the scl_source command is a fairly recent addition so hopefully you have it. See:


    Try it from a command line first before committing it to your .bashrc

    There are some things on the web about using django and uWSGI with software collections. For instance:


    but I know nothing about any of the applications so I don’t know how relevant this is.


  • No. I’m not entirely sure that is a good idea! No, not all.

    ‘scl enable python27 bash’ creates a *new* shell with the correct environment. As each invocation of bash reads .bashrc, it will also create another new shell which will then read .bashrc and create another shell ….

    Depending on the speed of your machine and disks and how much memory you have, it will take a few seconds to a few minutes to grind your machine to a halt.


  • I definitely wouldn’t make it the default python, but I have made it the default for a particular user as long as they are not root.

    In the past I have got python27-mod_wsgi and httpd24-httpd working together by doing things like httpd24-httpd by doing things like

    cat /opt/rh/httpd24/root/etc/sysconfig/httpd

    export PATH=/opt/rh/python27/root/usr/bin:$PATH
    export LD_LIBRARY_PATH=/opt/rh/python27/root/usr/lib64${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}

  • I am running nginx and uWSGI. I added this to /etc/systemd/system/uwsgi.service:

    ExecStart=/usr/bin/scl enable python27 bash; /usr/bin/uwsgi –emperor

    But it did not start:

    Loaded: loaded (/etc/systemd/system/uwsgi.service; enabled; vendor preset: disabled)
    Active: failed (Result: start-limit) since Mon 2017-12-11 17:20:36
    EST; 6s ago
    Process: 24492 ExecStart=/usr/bin/scl enable python27 bash;
    /usr/bin/uwsgi –emperor /etc/uwsgi/sites (code=exited, status=1/FAILURE)

  • With that change it starts, but still with 2.7.5:

    *** Starting uWSGI (64bit) on [Mon Dec 11 17:47:19 2017] ***
    compiled with version: 4.8.5 20150623 (Red Hat 4.8.5-4) on 28 July 2016 12:32:18
    os: Linux-3.10.0-327.36.3.el7.x86_64 #1 SMP Mon Oct 24 16:09:20 UTC 2016
    nodename: padev machine: x86_64
    clock source: unix detected number of CPU cores: 8
    current working directory: /etc/uwsgi/sites detected binary path: /usr/bin/uwsgi chdir() to /usr/local/motor/motor your processes number limit is 195775
    your memory page size is 4096 bytes detected max file descriptor number: 1024
    lock engine: pthread robust mutexes thunder lock: disabled (you can enable it with –thunder-lock)
    uwsgi socket 0 bound to UNIX address /usr/local/motor/motor.sock fd 3
    Python version: 2.7.5 (default, Sep 15 2016, 22:37:39) [GCC 4.8.5
    20150623 (Red Hat 4.8.5-4)]
    *** Python threads support is disabled. You can enable it with
    –enable-threads ***
    Python main interpreter initialized at 0x13a75e0
    your server socket listen backlog is limited to 100 connections your mercy for graceful operations on workers is 60 seconds mapped 1115752 bytes (1089 KB) for 10 cores
    *** Operational MODE: preforking ***
    WSGI app 0 (mountpoint=”) ready in 0 seconds on interpreter 0x13a75e0
    pid: 25616 (default app)
    *** uWSGI is running in multiple interpreter mode ***
    spawned uWSGI master process (pid: 25616)
    spawned uWSGI worker 1 (pid: 25693, cores: 1)
    spawned uWSGI worker 2 (pid: 25694, cores: 1)
    spawned uWSGI worker 3 (pid: 25695, cores: 1)
    spawned uWSGI worker 4 (pid: 25696, cores: 1)
    spawned uWSGI worker 5 (pid: 25697, cores: 1)
    spawned uWSGI worker 6 (pid: 25699, cores: 1)
    spawned uWSGI worker 7 (pid: 25700, cores: 1)
    spawned uWSGI worker 8 (pid: 25701, cores: 1)
    spawned uWSGI worker 9 (pid: 25702, cores: 1)
    spawned uWSGI worker 10 (pid: 25703, cores: 1)

  • After I issue the command scl enable python27 bash, and my python is then 2.7.13, when I run pip will it use 2.17.13 to build what I am downloading?

  • Larry Martell wrote:

    I guess my very brief suggestion wasn’t understood: in whatever shell script you use to start the tools you want to use, insert, at the top, right under the #!/bin/bash, the line
    . /opt//enable so that the paths are set for that shell script, and all its children. This will not result in you going into python’s command line, nor will it affect anything else, including yum.


  • Sorry, missed your previous post. Ended up that I had to reinstall uWSGI using the 2.5.13 pip, and then link
    /opt/rh/python27/root/usr/bin/uwsgi to /usr/bin/uwsgi. Now that I have it running, hopefull it will resolve the issue I had (which was a bug in the 2.7.5 zlib).