Install python 2.6 in CentOS

Question

I have a shell that runs CentOS.

For a project I'm doing, I need python 2.5+, but centOS is pretty dependent on 2.4.

From what I've read, a number of things will break if you upgrade to 2.5.

I want to install 2.5 separately from 2.4, but I'm not sure how to do it. So far I've downloaded the source tarball, untarred it, and did a ./configure --prefix=/opt which is where I want it to end up. Can I now just make, make install ? Or is there more?

Answer 1

Type the following commands on the terminal to install Python 3.6 on CentOS 7:

$ sudo yum install https://centos7.iuscommunity.org/ius-release.rpm

Then do :

$ sudo yum install python36u 

You can also install any version instead of 3.6 (if you want to) by just replacing 36 by your version number.

Answer 2

You could also use the EPEL-repository, and then do sudo yum install python26 to install python 2.6

Answer 3

Try epel

wget http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm
sudo rpm -ivh epel-release-5-4.noarch.rpm
sudo yum install python26

The python executable will be available at /usr/bin/python26

mkdir -p ~/bin
ln -s /usr/bin/python26 ~/bin/python
export PATH=~/bin:$PATH # Append this to your ~/.bash_profile for persistence

Now, python command will execute python 2.6

Answer 4

No, that's it. You might want to make sure you have all optional library headers installed too so you don't have to recompile it later. They are listed in the documentation I think.

Also, you can install it even in the standard path if you do make altinstall. That way it won't override your current default "python".

Answer 5

Late to the party, but the OP should have gone with Buildout or Virtualenv, and sidestepped the problem completely.

I am currently working on a Centos server, well, toiling away would be the proper term and I can assure everyone that the only way I am able to blink back the tears whilst using the software equivalents of fire hardened spears, is buildout.

Answer 6

When I've run into similar situations, I generally avoid the package manager, especially if it would be embarrassing to break something, i.e. a production server. Instead, I would go to Activestate and download their binary package:

https://www.activestate.com/activepython/downloads/

This is installed by running a script which places everything into a folder and does not touch any system files. In fact, you don't even need root permissions to set it up. Then I change the name of the binary to something like apy26, add that folder to the end of the PATH and start coding. If you install packages with apy26 setup.py installor if you use virtualenv and easyinstall, then you have just as flexible a python environment as you need without touching the system standard python.

Edits... Recently I've done some work to build a portable Python binary for Linux that should run on any distro with no external dependencies. This means that any binary shared libraries needed by the portable Python module are part of the build, included in the tarball and installed in Python's private directory structure. This way you can install Python for your application without interfering with the system installed Python.

My github site has a build script which has been thoroughly tested on Ubuntu Lucid 10.04 LTS both 32 and 64 bit installs. I've also built it on Debian Etch but that was a while ago and I can't guarantee that I haven't changed something. The easiest way to do this is you just put your choice of Ubuntu Lucid in a virtual machine, checkout the script with git clone git://github.com/wavetossed/pybuild.git and then run the script.

Once you have it built, use the tarball on any recent Linux distro. There is one little wrinkle with moving it to a directory other than /data1/packages/python272 which is that you have to run the included patchelf to set the interpreter path BEFORE you move the directory. This affects any binaries in /data1/packages/python272/bin

All of this is based on building with RUNPATH and copying the dependent shared libraries. Even though the script is in several files, it is effectively one long shell script arranged in the style of /etc/rc.d directories.