Das deutsche Python-Forum

Diese Anleitung ist für Leute gedacht, die eine Installation mittels Quellcode-Kompilierung aus dem aktuellen SVN-Entwicklungszweig machen wollen (derzeit Python 3.3a0), um neu hinzugekommene Funktionen auszuprobieren. Sie ist für Debian-basierte Systeme geschrieben, dürfte aber mit ein paar Modifikationen auch unter anderen Linux-Distributionen funktionieren. Als üblichen Disclaimer bitte ich zu beachten, dass solche Versionen naturgemäß nicht für den produktiven Einsatz und folglich eher für Interessierte zum Testen geeignet sind.

Nun, das Ganze ist nicht sooo wahnsinnig kompliziert und dürfte auch dem Einen oder Anderen bereits geläufig sein. Ich zeige die Schritte aber trotzdem mal mit ein paar Erklärungen:

Um den aktuellen Stand zu laden, benötigt man zunächst natürlich SVN selbst, welches beispielsweise mit dem Debian-Paket `subversion` auf den Rechner gelangen kann. Als nächstes werden für ein erfolgreiches Kompilieren folgende Debian-Pakete benötigt (welche teilweise auch schon auf dem System vorhanden sein können): Dann lädt man sich entsprechend den Zweig auf den Rechner: Nun in das neu erstellte Verzeichnis `py3k` wechseln und dort das Konfigurationsskript ausführen: Dann den Code kompilieren lassen: Und zum Schluss mit Root-Rechten noch ein: Damit wird Python so installiert, dass es die vorhandene Produktivversion nicht stört und auch einer möglichen späteren Installation mittels Paketverwaltung nicht im Wege steht. Es ist dann durch Anfügen der Versionsnummer aufrufbar: Nochmal der Vergleich: Ungläublich, nicht wahr?

Falls man irgendwann mal updaten will, startet man im `py3k`-Verzeichnis ein: Die Schritte zum Kompilieren müssen danach logischerweise wiederholt werden.

@snafu: Vielleicht sollte man SVN durch Mercurial ersetzen. Bin verwundert, dass die überhaupt noch SVN anscheinend parallel (!?) mit commits versorgen.

http://docs.python.org/devguide/setup.h ... ource-code

Da eine Entwicklungsversion kaum für systemweite Programme verwendet wird, sehe ich irgendwie keinen Sinn darin, sie systemweit zu installieren. Insofern würde ich persönlich eher "./configure --prefix=$HOME" nutzen. So sind keine Root-Rechte nötig, und es besteht weniger Gefahr durch einen falschen Befehl die systemweite Standardinstallation zu beschädigen.

Davon abgesehen würde ich, wenn ich Sachen schon am Paketmanager vorbei systemweit installiere (was ich, hmm, eigentlich nie tue) dann als Prefix ``/usr/local`` setzen, um etwaigen Konflikten vorzubeugen. Und um ne übersicht über lokal installierten Krams zu haben.

Und ja, für sowas hat lunar natürlich recht, ich installiere Entwicklerversionen von Python auch nur in $HOME (außer mein Paketmanager bringt auch dafür Pakete mit).

@Leonidas: Da braucht man nichts setzen -- /usr/local/ ist der Normalfall/Defaultwert. Das sieht man doch beim ``which`` im ersten Beitrag ganz gut.

Oh, tatsächlich Ich bin davon ausgegangen das es, wie viele andere Software, sich rücksichtslos in ``/usr`` installiert.

@Leonidas: Was installierst Du für Software!?

Die Mehrzahl der Software, die ich aus Quellen installiere verwendet ein Buildsystem -- meistens Autotools oder CMake -- und deren Vorgabe ist eigentlich immer `/usr/local/`.

BlackJack hat geschrieben:Vielleicht sollte man SVN durch Mercurial ersetzen.

Ich finde da allerdings als höchste Version nur den Zweig/Tag für Python 3.2, also logischerweise nicht der Entwicklerversion. Ich will natürlich nicht auschließen, dass ich etwas übersehen haben könnte. Wäre dankbar für einen Hinweis.

EDIT: Ah, ein Klick auf http://svn.python.org/view/python/branches/py3k leitet direkt zum Mercurial-Repo weiter. Das ist vermutlich dann auch die Antwort auf deine Frage, inwiefern da synchronisiert wird. Wohl eher kein paralleles Comitten (zum Glück).

Wobei, bevor ich wieder voreilige Schlüsse aus Halbwissen ziehe: Ist es technisch überhaupt möglich innerhalb eines Repos eine Weiterleitung auf ein anderes Repo zu machen?

@snafu: Die Entwicklerversion hat keinen speziellen Namen, man muss also auch keinen Branch angeben wenn man das aktuellste haben möchte. In der Übersicht hier ist das der 'default'-Branch: http://hg.python.org/cpython/branches

Kein Name beziehungsweise 'default' ist sozusagen das wofür 'trunk/' üblicherweise in Subversion steht.

Die Weiterleitung ist bestimmt mit HTTP oder Möglichkeiten des Servers realisiert. Ich glaube nicht, dass bei einem SVN-Checkout das Mercurial-Repo geladen wird.
Und das SVN Repo ist seit dem Umstieg read-only und die Commits werden mit Cron-Jobs oder so aktualisiert. Meine das auf der Mailing-List gelesen zu haben, etwas anderes würde eigentlich keinen Sinn ergeben. Bin mir allerdings nicht 100% sicher.

Die "Sicherheit" bei einer Installation in `/usr/local/bin/` muss ich übrigens etwas relativieren: Zumindest bei mir (Ubuntu) stehen die `local`-Varianten als erstes im PATH, so dass bei einer Installation mittels Paketverwaltung trotzdem noch das manuell installierte Python ausgeführt würde, da die Shell ja aufhört, sobald beim Durchgehen der aufgeführten Pfadangaben eine Datei im entsprechenden Verzeichnis gefunden wird und diese Datei dann ausführt. Da sollte man also entweder das manuell installierte Python aus dem Verzeichnis schmeißen oder den PATH anpassen. Letzteres wäre IMHO die bessere Idee. Will man ganz sicher gehen, macht man es sogar so wie Leonidas und lunar vorgeschlagen haben und setzt sich entsprechend `$HOME/bin` in den PATH.

@snafu: Das `/usr/local/bin/` vor `/usr/bin/` im $PATH liegt, ist nicht nur bei Ubuntu so. Das ist auch so gewollt, denn man *will* ja, dass "lokal" installiertes das vom System "verdeckt". Die Sicherheit bezieht sich darauf, dass man nichts überschreibt was von der Paketverwaltung der Distribution verwaltet wird und auch das ein Update über die Systemverwaltung nicht das selbst installierte wieder überschreiben kann.

Naja, es ist ja eben nicht immer so gewollt. Abgesehen von parallel laufenden Python-Versionen kann es ja auch sein, dass man eine neue Software installiert hat, die es für die eigene Distribution nicht als Paket gibt. Nun wird einige Zeit später ein Paket erstellt und man installiert sich dieses. Da möchte man meistens schon die Version aus der Paketverwaltung benutzen, wenn der Befehl aufgerufen wird, weil eben diese ja auch aktualisiert wird. Solange man den PATH so lässt wie er ist, wird man aber weiterhin nur die manuell installierte Version nutzen können, weil die ja als Erstes gefunden wird.

Und was das Thema "Sicherheit" nochmal in Bezug auf Python angeht: Bei mir ist `/usr/bin/python` auf `python2.6` verlinkt und `/usr/bin/python3` auf `python3.1`. Ich betone, dass jeweils kein absoluter Pfad angegeben wurde, sondern es wird sich offenbar auf die Interpretation des PATH durch die Shell verlassen. Spinnen wir mal weiter, dass Ubuntu jetzt schon bei Python 3.2 wäre und ich durch irgendein PPA die gerade aktuell gewordene Version 3.3 beziehen kann (ja, wir sind gedanklich bei Anfang 2012 oder so). Nun dürfte der Link für `/usr/bin/python` (der 2.x-Zweig ist in dem Beispiel nicht mehr der Standard) ja auf `python3.3` zeigen. Das wird jetzt halt zu `/usr/local/bin/python3.3` aufgelöst, womit alle Python-Skripte die manuelle Version nutzen, welche seit Monaten auf dem System schlummert, ohne Updates erfahren zu haben.

Ich gebe zu, das alles ist natürlich arg zusammenkonstruiert. Trotzdem soll es zeigen, dass die Reihenfolge im PATH so wie sie ist zwar nicht grundsätzlich schlecht ist, aber durchaus gewisse Gefahren bergen kann. Wobei im Prinzip natürlich die dahinterliegende Ursache der User ist, welcher munter an der Paketverwaltung vorbei installiert hat. Ich wollte mit dem Gedankenkonstrukt in erster Linie auch nur das Argument von BJ zumindest relativieren.

@snafu: Doch es ist immer so gewollt. Du kannst die Pfade in der Suchreihenfolge nicht einfach umkehren. Historisch ist das so gewachsen, dass `/usr/bin` & Co von einem Sysadmin gepflegt wurde und auf vielen Rechnern über das Netzwerk eingehängt wurde. Wenn Software auf einem Rechner von der allgemeinen Installation abweichen sollte, dann wurde die für den Rechner "lokal" in `/usr/local/` installiert. Und muss dann natürlich auch *vor* der allgemeinen Installation gesucht werden, sonst macht das ja gar keinen Sinn. Eine Paketverwaltung hat in heutigen Distributionen den Sysadmin ersetzt, der die Installation der Software pflegt. Im Grunde ist es ja aber immer noch so, dass jemand anderes die Sachen kompiliert und bestimmt was wo hin kommt. Und dem (der Paketverwaltung) möchte man sich heute genau so wenig in die Quere kommen, wie früher dem Administrator. Ein System bei dem die Suchreihenfolge umgedreht ist, wäre IMHO ziemlich kaputt, weil damit eine wirklich grundlegende Erwartung bezüglich des Verhaltens verletzt wird.

Wenn man eine Software selber installiert und dann später die selbe Software aus der Paketverwaltung, dann ist man selbst dafür verantwortlich dass man die "lokale" Version deinstalliert. Und weil es dieses Arrangement mit `/usr/local/` gibt, *kann* man das auch, ohne die von der Paketverwaltung installierten Dateien anfassen zu müssen.

Deine Sorgen bezüglich der Links sind unbegründet, denn es würde weiterhin die richtige Version gestartet: Wenn ein symbolischer Link nicht absolut ist, dann ist er relativ zum Link. Da wird nicht im $PATH gesucht.

Übrigens wären in der Regel nicht einmal in `/usr/bin/` installierte Python-Skripte betroffen wenn man nicht ``altinstall`` verwendet, weil als die installiert wurden, der volle Pfad zum Interpreter in die ``#!``-Zeile geschrieben wurde, der zum Starten der `setup.py` verwendet wurde.

Okay, das alles wusste ich ganz offensichtlich wirklich nicht.

Nochmal was zum Repo-Wechsel: http://docs.python.org/dev/whatsnew/3.2 ... repository