Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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
share|improve this question
add comment

2 Answers

up vote 3 down vote accepted

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.

share|improve this answer
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. –  Joel Davis May 27 '13 at 21:20
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. –  Joel Davis 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. –  Joel Davis May 27 '13 at 21:59
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. –  Joel Davis May 27 '13 at 22:29
show 5 more comments

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!

share|improve this answer
    
Can i not remove the Python 2.6 in my RHEL? What i will lose if i remove it? –  YumYumYum 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. –  YumYumYum May 27 '13 at 21:18
3  
@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
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.