1

My system is RedHat 5 Linux and has default python 2.4 installed. In order to execute Mercurial 1.81, I tried to upgrade python from 2.4 to 2.6 and I thought I saved it in a different directory. I have put hard link from python 2.6 to python. Now, I removed it and hope to make python pointing back to python 2.4 in order to avoid version conflicting.

Here is the command I have used to remove the hard link between python and python 2.6:

find -xdev -samefile /usr/bin/python | xargs rm

Then I used commands as:

ln -s /usr/bin/python2.4 /usr/bin/python
ln -s /usr/bin/python2.6 /usr/local/bin/python
export PATH=/usr/local/bin:$PATH
Change first line of hg to #!/usr/bin/env python
PYTHONHOME=/usr/lib/python2.6
PYTHONPATH=/usr/lib/python2.6 

Then when I typed whereis python, here are the results.

/usr/bin/python2.4 
/usr/bin/python 
/usr/lib/python2.4 
/usr/lib/python2.6 
/usr/local/bin/python 
/usr/include/python2.4 
/usr/include/python2.6 
/usr/share/man/man1/python.1.gz

Then when I typed which python, it pointed to usr/bin/python. When I typed python -V, it showed python 2.4.3. It seems to be pointing back to 2.4.3. Then, when I used the command

python -c "import sys; print '\n' .join(sys.path)"

It showed:

/usr/lib64/python24.zip
/usr/lib64/python2.4
/usr/lib64/python2.4/plat-linux2
/usr/lib64/python2.4/lib-tk
/usr/lib64/python2.4/lib-dynload
/usr/lib64/python2.4/site-packages
/usr/lib64/python2.4/site-packages/Numeric
/usr/lib64/python2.4/site-packages/gtk-2.0
/usr/lib/python2.4/site-packages

I tried to find the paths of python 2.6 by typing find / -name python2.6, it showed

/usr/include/python2.6
/usr/lib/python2.6
/usr/lib64/python2.6

Here are my questions :

  1. How can I change the replace the results from the on-liner above to python 2.6 ?
  2. Why cannot I find a directory such as /usr/bin/python2.6 or /usr/local/bin/python2.6 ? Does it mean I installed my python 2.6 incorrectly or accidentally removed the directory ? Is anything wrong about the results I got from those commands I entered ?
  3. Any idea how to make the system execute python 2.6 when I used "hg push" ?
  4. Should I install the python 2.6 again at /usr/local/bin ?
5
  • You only need Python 2.4 to run any version of Mercurial, even Mercurial 2.1. Are you trying to use Python 2.6 to get better support for verifying SSL certificates? Commented Mar 1, 2012 at 23:03
  • When I used command such as "hg push", the system complained with an error message such as "abort: certificate checking requires Python 2.6 ". I assume that means it requires Python 2.6 or I am wrong ? Thanks
    – Cassie
    Commented Mar 8, 2012 at 17:13
  • Python 2.6 is required to check the SSL certificates. I'm a bit surprised it aborts, but you can try with hg push --insecure to let Mercurial know that you cannot verify the certificates with your Python. I think you can also configure a host fingerprint, see the wiki page. Commented Mar 8, 2012 at 17:23
  • Hi Thank you so very much ~. I tried "hg push --insecure".It avoided the certificates error and let me push successfully. Will there be any problem if I used hg push --insecure ?
    – Cassie
    Commented Mar 9, 2012 at 21:49
  • @Raystafarian Did you help edit the question posted ? Thank you very much,:)
    – Cassie
    Commented Mar 9, 2012 at 21:51

1 Answer 1

0
  1. Install virtualenv and virtualenvwrapper (easy_install worked for me, but don't forget to add the line source /usr/local/bin/virtualenvwrapper.sh to your shell startup script and then source the startup script to use the wrapper)
  2. Run mkvirtualenv -p /usr/lib/python2.6 ENVNAME (where ENVNAME is whatever you want to name it, maybe hg?)
  3. Add workon ENVNAME to your shell init script (.profile, .*shrc, etc)

Now your system will still be able to use 2.4, and all of your shells will use 2.6. Be careful, because this could break calls to other system-installed applications, if their dependencies aren't in your virtual environment. But, since you now have pip, it should be easy to pip install $WHATEVER_IS_MISSING (or run the deactivate command to drop out of your virtual environment, do your thing, and workon back to where you were).

If you find hg instances started by processes outside of shells (e.g. file manager integration?) then I recommend placing this small script on your path and configuring those processes to invoke it instead.

#!/bin/bash # or whatever your shell is
workon ENVNAME
hg $*

(Note, you can disable the (ENVNAME) prompt by setting VIRTUAL_ENV_DISABLE_PROMPT earlier in your init script than the workon line)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .