3

RHEL 6.2 I have python 2.6 but I need default python 2.7 using yum packaging (so that nothing goes messed up, cause its a heavy duty working system, all I need the python 2.7 on it, without messing up).

I did following but still I see python version as 2.6, any pointer to this please?

$ cat /etc/issue
Red Hat Enterprise Linux Server release 6.2 (Santiago)
Kernel \r on an \m

$ python --version
Python 2.6.6

$ sudo sh -c 'wget -qO- http://people.redhat.com/bkabrda/scl_python27.repo >> /etc/yum.repos.d/scl.repo'

$ yum search python27
Loaded plugins: amazon-id, rhui-lb, security
scl_python27                                                                                                                                      | 2.9 kB     00:00     
scl_python27/primary_db                                                                                                                           |  38 kB     00:00     
========================================================================= N/S Matched: python27 =========================================================================
python27.i686 : Package that installs python27
python27.x86_64 : Package that installs python27
python27-expat-debuginfo.i686 : Debug information for package python27-expat
python27-expat-debuginfo.x86_64 : Debug information for package python27-expat
python27-python-coverage-debuginfo.i686 : Debug information for package python27-python-coverage
python27-python-coverage-debuginfo.x86_64 : Debug information for package python27-python-coverage
python27-python-debuginfo.i686 : Debug information for package python27-python
python27-python-debuginfo.x86_64 : Debug information for package python27-python
python27-python-markupsafe-debuginfo.i686 : Debug information for package python27-python-markupsafe
python27-python-markupsafe-debuginfo.x86_64 : Debug information for package python27-python-markupsafe
python27-python-simplejson-debuginfo.i686 : Debug information for package python27-python-simplejson
python27-python-simplejson-debuginfo.x86_64 : Debug information for package python27-python-simplejson
python27-python-sqlalchemy-debuginfo.i686 : Debug information for package python27-python-sqlalchemy
python27-python-sqlalchemy-debuginfo.x86_64 : Debug information for package python27-python-sqlalchemy
python27-runtime.i686 : Package that handles python27 Software Collection.
python27-runtime.x86_64 : Package that handles python27 Software Collection.
python27-babel.noarch : Tools for internationalizing Python applications
python27-build.i686 : Package shipping basic build configuration
python27-build.x86_64 : Package shipping basic build configuration
python27-expat.i686 : An XML parser library
python27-expat.x86_64 : An XML parser library
python27-expat-devel.i686 : Libraries and header files to develop applications using expat
python27-expat-devel.x86_64 : Libraries and header files to develop applications using expat
python27-expat-static.i686 : expat XML parser static library
python27-expat-static.x86_64 : expat XML parser static library
python27-python.i686 : An interpreted, interactive, object-oriented programming language
python27-python.x86_64 : An interpreted, interactive, object-oriented programming language
python27-python-babel.noarch : Library for internationalizing Python applications
python27-python-coverage.i686 : Code coverage testing module for Python
python27-python-coverage.x86_64 : Code coverage testing module for Python
python27-python-debug.i686 : Debug version of the Python runtime
python27-python-debug.x86_64 : Debug version of the Python runtime
python27-python-devel.i686 : The libraries and header files needed for Python development
python27-python-devel.x86_64 : The libraries and header files needed for Python development
python27-python-docutils.noarch : System for processing plaintext documentation
python27-python-jinja2.noarch : General purpose template engine
python27-python-libs.i686 : Runtime libraries for Python
python27-python-libs.x86_64 : Runtime libraries for Python
python27-python-markupsafe.i686 : Implements a XML/HTML/XHTML Markup safe string for Python
python27-python-markupsafe.x86_64 : Implements a XML/HTML/XHTML Markup safe string for Python
python27-python-nose.noarch : Discovery-based unittest extension for Python
python27-python-nose-docs.noarch : Nose Documentation
python27-python-pygments.noarch : Syntax highlighting engine written in Python
python27-python-setuptools.noarch : Easily build and distribute Python packages
python27-python-simplejson.i686 : Simple, fast, extensible JSON encoder/decoder for Python
python27-python-simplejson.x86_64 : Simple, fast, extensible JSON encoder/decoder for Python
python27-python-sphinx.noarch : Python documentation generator
python27-python-sphinx-doc.noarch : Documentation for python-sphinx
python27-python-sqlalchemy.i686 : Modular and flexible ORM library for python
python27-python-sqlalchemy.x86_64 : Modular and flexible ORM library for python
python27-python-test.i686 : The test modules from the main python package
python27-python-test.x86_64 : The test modules from the main python package
python27-python-tools.i686 : A collection of development tools included with Python
python27-python-tools.x86_64 : A collection of development tools included with Python
python27-python-virtualenv.noarch : Tool to create isolated Python environments
python27-python-werkzeug.noarch : The Swiss Army knife of Python web development
python27-python-werkzeug-doc.noarch : Documentation for python-werkzeug
python27-tkinter.i686 : A graphical user interface for the Python scripting language
python27-tkinter.x86_64 : A graphical user interface for the Python scripting language

EDIT: (alternative option I also tried as following):

#!/bin/bash
# Install Python 2.7.3 alternatively
yum groupinstall "development tools" -y
yum install readline-devel openssl-devel gmp-devel ncurses-devel gdbm-devel zlib-devel expat-devel libGL-devel tk tix gcc-c++ libX11-devel glibc-devel bzip2 tar tcl-devel tk-devel pkgconfig tix-devel bzip2-devel sqlite-devel autoconf db4-devel libffi-devel valgrind-devel -y

mkdir tmp
cd tmp
wget http://python.org/ftp/python/2.7.3/Python-2.7.3.tgz
tar xvfz Python-2.7.3.tgz
cd Python-2.7.3
./configure --prefix=/opt/python2.7 --enable-shared
make
make altinstall
echo "/opt/python2.7/lib" >> /etc/ld.so.conf.d/opt-python2.7.conf
ldconfig
cd ..
cd ..
rm -rf tmp


[root@ip-10-59-143-73 bin]# pwd
/opt/python2.7/bin
[root@ip-10-59-143-73 bin]# tree
.
├── 2to3
├── idle
├── pydoc
├── python2.7
├── python2.7-config
└── smtpd.py

0 directories, 6 files
[root@ip-10-59-143-73 bin]# ./python2.7 --version
Python 2.7.3

[root@ip-10-59-143-73 bin]# python --version
Python 2.6.6
slm
  • 369,824

3 Answers3

3

Rather than mess with the system level Python, might I suggest using something like virtualenv together with virtualenvwrapper. Together these 2 tools make it pretty trivial to stand up your own local copies of Python + libraries instead of having to try and keep the system level installation of Python in an OK state for the system level software that requires it.

virtualenv

virtualenv is a tool to create isolated Python environments.

It creates an environment that has its own installation directories, that doesn't share libraries with other virtualenv environments (and optionally doesn't access the globally installed libraries either).

virtualenvwrapper

virtualenvwrapper is a set of extensions to Ian Bicking's virtualenv tool. The extensions include wrappers for creating and deleting virtual environments and otherwise managing your development workflow, making it easier to work on more than one project at a time without introducing conflicts in their dependencies.

Most languages provide these types of tools now. See my post on this question titled: Recommended Linux distribution for statistics? for other languages as well.

Community
  • 1
slm
  • 369,824
  • 2
    Yeah, I'll second this notion. Installing a core operating system component like python from a third party repo and then removing the version of python everything is going to list as a dependency is just asking for trouble. This is especially true since python27 probably installs to non-standard directories to prevent itself from clobbering the native python install. – Bratchley May 27 '13 at 21:20
  • @JoelDavis: how can i just tell to use the non-standard directories so that it uses python27 which i installed rather then its using python26 –  May 27 '13 at 21:52
  • 2
    I really don't recommend doing this. There are going to be things that come with RHEL that are designed for and will assume the existence of python 2.6. If your hope is to take advantage of some of the bug fixes, you should be aware that Red Hat backports upstream fixes (those from the main project) by way of a patch to the package versions their platform is going to assume exists. The patch version number is the part of the package name after the hyphen but before the hardware architecture stuff. – Bratchley May 27 '13 at 21:56
  • 2
    What are you hoping to get by making it the system default? Maybe there's another way of doing this that won't cause headaches for you later. slm's virtualenv solution seems like a good alternative. – Bratchley May 27 '13 at 21:59
  • Should i do like this to have python27 as optional ? http://pastebin.com/t6uBa3uZ –  May 27 '13 at 22:00
  • I want python26 remain as it is. but i need python27 only for one application where i can tell manually use /path/python27 as python, so that it does not use the systems python26 –  May 27 '13 at 22:01
  • 1
    We've used this approach for several years for a variety of apps. It's really no different than including your own JAVA JDK on a box for each app based on it's needs. It's just a little less familiar to people to do it with the dynamic languages, especially using a tool to manage the python2.7 tree for you using virtualenv. BTW the installs that virtualenv creates are portable too. We typically build on one machine and then move them around. – slm May 27 '13 at 22:08
  • 1
    @YumYumYum, would it be possible to create a symlink to /usr/bin/python in some new directory and just add that to the beginning of the PATH variable before you launch the application? It's possible (and probable) that the name of the python executable is the only thing hard coded in the application, and once it start running it lets the interpretter figure out where everything is. – Bratchley May 27 '13 at 22:29
  • 1
    Alternatively, if the application is written in python can't you just manually specify the non-standard interpreter as part of the command you use to start it? Meaning, for example: # python27 startApplication.py instead of just # ./startApplication.py . – Bratchley May 27 '13 at 22:30
  • 1
    @JoelDavis: Thanks its working now with my python27 using manual path like your suggestion. –  May 27 '13 at 22:33
2

The Red Hat supported approach to installing newer versions of Python on RHEL releases is Red Hat Software Collections: https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/2/html/2.0_Release_Notes/chap-RHSCL.html#sect-RHSCL-Features

RHSCL 2.0 includes Python 2.7.8 and 3.4.2.

For CentOS users, the upstream to RHSCL is at https://www.softwarecollections.org/

ncoghlan
  • 1,001
1

I am using Python 2.7.4 on RedHat 6.4 for scientific computing. The easiest way to install it is to use enthought Python distribution (EPD) which installs pre-compiled binaries in the sandbox. It populates gnome menus accordingly. You can also edit your profile (I use ksh) and set path to enthought Python instead of the system one. Use soft links if you need it in some specific application. EPD is free for academic use. If you need it in production I would suggest that you buy a license or play with your own sandbox. Either way is not going to be free.

Edit: Do NOT mess up with the system Python. Yum is written in Python. RedHat can not work without Python!

Predrag Punosevac
  • 339
  • Can i not remove the Python 2.6 in my RHEL? What i will lose if i remove it? –  May 27 '13 at 21:17
  • And then install fresh Python 2.7 on it. Cause all both answers seems not the issue while using Ubuntu only on RHEL everything has issues. –  May 27 '13 at 21:18
  • 4
    @YumYumYum NO!!! Absolutely not! RedHat uses Python in its systems tools. You do not want to mess with system Python no matter how obsolete it might look to you. – Predrag Punosevac May 27 '13 at 21:21