Jak sprawić, by Mercurial znalazł zaktualizowaną wersję Pythona?

Mój system to RedHat 5 Linux i ma domyślnie zainstalowany Python 2.4 . Aby uruchomić Mercurial 1.81, próbowałem zaktualizować Pythona z 2.4 do 2.6 i pomyślałem, że zapisałem go w innym katalogu. Umieściłem twardy link z Pythona 2.6 do Pythona . Teraz go usunąłem i mam nadzieję, że Python będzie wskazywał na Python 2.4 , aby uniknąć konfliktu wersji.

Oto polecenie, którego użyłem do usunięcia twardego łącza między Pythonem a Pythonem 2.6 :

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

następnie użyłem poleceń jako:

 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

Potem, gdy wpisałem „whereis python”, oto wyniki.

python: /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

Potem, kiedy pisałem which python, wskazał usr/bin/python. Kiedy pisałem python -V, pokazało się python 2.4.3. Wydaje się wskazywać na 2.4.3 . Potem, kiedy użyłem polecenia

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

to pokazało

 /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

Próbowałem znaleźć ścieżki do Pythona 2.6 , pisząc find / -name python2.6, że to pokazuje

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

Oto moje pytania:

Jak mogę zmienić zamianę wyników z powyższej wersji na Python 2.6 ?
Dlaczego nie mogę znaleźć katalogu takiego jak /usr/bin/python2.6lub /usr/local/bin/python2.6? Czy to znaczy, że źle zainstalowałem mój python 2.6 lub przypadkowo usunąłem katalog? Czy coś jest nie tak z wynikami, które uzyskałem po wpisaniu poleceń?
Masz pomysł, jak zmusić system do uruchomienia Pythona 2.6, gdy użyłem „hg push”?
Czy powinienem ponownie zainstalować Python 2.6 w / usr / local / bin?

— Cassie
źródło

Potrzebujesz tylko Pythona 2.4, aby uruchomić dowolną wersję Mercurial, nawet Mercurial 2.1. Czy próbujesz użyć języka Python 2.6, aby uzyskać lepszą obsługę weryfikacji certyfikatów SSL?

— Martin Geisler

Kiedy użyłem polecenia takiego jak „hg push”, system narzekał na komunikat o błędzie, taki jak „przerwanie: sprawdzanie certyfikatu wymaga Pythona 2.6”. Zakładam, że oznacza to, że wymaga Python 2.6 lub się mylę? Dzięki

— Cassie,

Python 2.6 jest wymagany do sprawdzania certyfikatów SSL. Jestem trochę zaskoczony, że przerywa, ale możesz spróbować hg push --insecurepoinformować Mercurial, że nie możesz zweryfikować certyfikatów za pomocą Pythona. Myślę, że możesz również skonfigurować odcisk palca hosta, zobacz stronę wiki .

— Martin Geisler,

Cześć Dziękuję bardzo ~. Próbowałem „hg push --insecure”. Pozwoliło to uniknąć błędu certyfikatów i pozwoliło mi pomyślnie przesłać. Czy będzie jakiś problem, jeśli użyję hg push --insecure?

— Cassie,

@Raystafarian Czy pomogłeś w edycji opublikowanego pytania? Dziękuję bardzo :)

— Cassie,

Zainstaluj virtualenv i virtualenvwrapper (easy_install zadziałało dla mnie, ale nie zapomnij dodać linii source /usr/local/bin/virtualenvwrapper.shdo skryptu uruchamiania powłoki, a następnie źródła skryptu uruchamiania, aby użyć opakowania)
Uruchom mkvirtualenv -p /usr/lib/python2.6 ENVNAME( ENVNAMEmoże jak chcesz to nazwać hg?)
Dodaj workon ENVNAMEdo skryptu inicjującego powłokę (.profile,. * Shrc itp.)

Teraz twój system będzie nadal mógł używać 2.4, a wszystkie twoje powłoki będą używać 2.6. Zachowaj ostrożność, ponieważ może to przerwać połączenia z innymi aplikacjami zainstalowanymi w systemie, jeśli ich zależności nie są w środowisku wirtualnym. Ale ponieważ masz teraz pip, powinno to być łatwe pip install $WHATEVER_IS_MISSING(lub uruchomić deactivatepolecenie, aby porzucić środowisko wirtualne, zrobić swoje i workonwrócić do miejsca, w którym byłeś).

Jeśli znajdziesz instancje hg uruchomione przez procesy poza powłokami (np. Integracja menedżera plików?), Zalecam umieszczenie tego małego skryptu na ścieżce i skonfigurowanie tych procesów, aby go wywoływały.

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

(Uwaga: możesz wyłączyć (ENVNAME)monit, ustawiając VIRTUAL_ENV_DISABLE_PROMPTwcześniej w skrypcie init wcześniej niż workonwiersz)

— Nate Parsons
źródło