Welche Methoden gibt es Python zuinstallieren ?

[debianfrischling]

Hallo,

ich brauche auf allen Systemen (Windows, Mac, Linux) die gleiche Version
von Python 2.6.5 oder 2.6.6.

Vorhanden Lenny 5.0.6.

Wie gehe ich am besten vor?

Sid nehmen und wie installieren?

Source von Python.org nehmen und wie installieren?

Backport bauen wovon und wie?

Mit virtualenz und wie?

Gibt es noch andere Möglichkeiten?

debianfrischling

[novalix]

Hi,
Python ist für Debian ziemlich grundlegend. Die Version in Lenny ist für Deine Ansprüche definitiv nicht die richtige. Ob man eine frischere Version parallel installieren kann, ist mir nicht geläufig. Ich nehme aber an, dass Du Dir damit Probleme einhandeln könntest.
Die Version aus Squeeze (testing) sollte Deinen Erfordernissen jedoch Rechnung tragen.
Dementsprechend könntest Du entweder einen virtualisierten Squeeze-Gast anlegen oder Dein System ganz auf Squeeze upgraden, was bedeutend einfacher zu handhaben sein sollte als Sid.

Als Virtualisierungslösungen bieten sich Linux-Vserver (ohne GUI) oder Virtualbox (mit Gui) an. Zur Installation sollte bei Google einiges zu finden sein. Rocket Science ist beides nicht.

Falls Du Dich für den Upgrade auf Squeeze entscheiden solltest, gehe bitte folgendermaßen vor:

1. Ändere die Einträge in der /etc/apt/sources.list von "lenny" bzw. "stable" zu "squeeze".
2. Führe ein Update der Paketdatenbank aus

Code: Alles auswählen

aptitude update

oder

Code: Alles auswählen

apt-get update

Je nach dem mit welchem dieser beiden Tools Du vertraut bist.
3. Installiere den 32er Kernel aus Squeeze, der zu Deiner Architektur passt. Z. B.

Code: Alles auswählen

aptitude install linux-image-2.6.32-5-686

für 32-bit
4. Reboote das System und stelle sicher, dass dies mit dem neuen 32er Kernel geschieht (sollte per Default so sein)
5. Führe das Upgrade durch

Code: Alles auswählen

aptitude full-upgrade

oder

Code: Alles auswählen

apt-get dist-upgrade

Der Kernel muss im Vorfeld aktualisiert werden, damit sich udev wohl und kuschelig fühlt. Sonst raubt es Dir den Upgradespass mit jeder Menge Meckerei und Hängerei.
Das kann niemand wollen.

Groetjes, niels

[debianfrischling]

MoinMoin Niels,

das hat wunderbar geklappt. Danke für die Anleitung.

Ich habe jetzt mal eine Frage zum Thema, wie baue ich mir ein eigenes Paket, das ich normal auf einem System mit apt-get installieren kann. Ich möchte ja nicht jedemal meine Linuxversion ändern.

Tipps, Links, Anleitungen, Buchempfehlung ect.

Gruss debianfrischling

[dawg]

Die ersten beiden links sind in englischer Sprache:
http://forums.debian.net/viewtopic.php? ... 76&start=0
https://sites.google.com/site/stevosfil ... edirects=0
Ich benutze den ersten von den beiden, um es zu lernen
(und den halte ich auch für gut)

Ich habe mal im Ubuntu-wiki was gefunden, kann es aber jetzt nicht mehr finden.
Versuch dich mal zu was Brauchbarem durchzuklicken:
http://wiki.ubuntuusers.de/Paketbau

Ob das aber in grossem Stil wirklich nötig ist? Wohl eher nicht.
Wahrscheinlich wäre es besser dauerhaft Testing zu nutzen, und bei Bedarf Pakete aus Sid bzw. Experimental zu installieren. Wenn die auch nicht aktuell genug sind, .... dann wird's schwierig.

Ach so, klar:

Code: Alles auswählen

apt-get install developers-reference

Da hört der Spass dann endgültig auf.

[suno]

Hi,
Python ist für Debian ziemlich grundlegend. Die Version in Lenny ist für Deine Ansprüche definitiv nicht die richtige. Ob man eine frischere Version parallel installieren kann, ist mir nicht geläufig. Ich nehme aber an, dass Du Dir damit Probleme einhandeln könntest.

In testing/sid kannst du via APT parallel Python 2.x (aktuell 2.6.6)und Python 3 (3.1) ohne Probleme installieren. Wenn das noch nicht reicht schlage ich vor ein virtualenv zu verwenden (wesentlich "lighther" als virtualizierung (auch wenn es operating system virtualization e.g. OpenVZ oder LVS ist).

http://www.markus-gattol.name/ws/python ... nvironment

[martin1967]

Leider ist mir unklar inwieweit die gleiche Python Version auf allen Maschinen auch gleichzeitig deren Standardversion sein muss, aber da ohnehin schon Virtualisierung angesprochen wurde, hier noch die eher einfache Variante.
Kompiliere einfach sämtliche Pythonversionen die du parallel haben willst selbst mit einem Zielordner für die Installation in deinem home Verzeichnis.
Dieser Link gibt die ein einfaches Beispiel wie der configure Befehl dafür auszusehen hat, das ist am flexibelsten und verursacht wenig Kopfschmerzen. Nebenbei angemerkt gehe ich so auch beim parallelen Einsatz verschiedenster Gnu Octave Versionen auf der gleichen Maschine vor, mit Python geht das genauso.

http://eli.thegreenplace.net/2008/10/20 ... -bluehost/

[novalix]

Leider ist mir unklar inwieweit die gleiche Python Version auf allen Maschinen auch gleichzeitig deren Standardversion sein muss

Muss es mit hoher Wahrscheinlichkeit auch nicht. Allerdings sind mir die Best Practices für Pythonentwickler auf Debian wie bereits angedeutet nicht geläufig. Dagegen ist es mindestens unter Debian wichtig, dass man mit der Standardversion keinen Schindluder treibt, indem man diese sauber von seiner Entwicklungsumgebung getrennt hält, falls man dafür eine andere teilweise inkompatible Version benötigt.
Bei einer Sprache wie GNU Octave ist das wesentlich unkomplizierter. Die Version von Octave interessiert z. B. die Bootskripte von Debian nicht die Bohne; die von Python schon.
Kurz gesagt: Wenn man mit der Standardversion von Python als Entwicklungsumgebung hinkommt, erspart man sich einiges an Arbeit und kann an eine grosse Zahl von Modulen und Libraries einfach über die Paketverwaltung zugreifen.

Groetjes, niels

[martin1967]

Bei einer Sprache wie GNU Octave ist das wesentlich unkomplizierter. Die Version von Octave interessiert z. B. die Bootskripte von Debian nicht die Bohne; die von Python schon.
Kurz gesagt: Wenn man mit der Standardversion von Python als Entwicklungsumgebung hinkommt, erspart man sich einiges an Arbeit und kann an eine grosse Zahl von Modulen und Libraries einfach über die Paketverwaltung zugreifen.

Genau diese saubere Trennung erreicht man ja gerade, wenn man die verschiedenen Python Versionen, welche man zur Entwicklung benötigt sauber als für das Linux System nicht sichtbare Varianten in Unterordner von home bzw. /usr/local/pythonxyz installiert (letzterese falls das Ganze auch für andere Anwender zu bestimmten Zwecken verfügbar sein muss). Dann hat man eben genau die Kapselung die einem garantiert, dass keinerlei Seiteneffekte mit dem zugrundeliegenden Debiansystem auftreten.
Selbstredend kann man diese natürlich nicht mit python aufrufen sondern braucht einen geigneten Starter, der die entsprechenden Umgebungsvariable suaber setzt, damit die entsprechende Pythoninstallation auch weiss wo ihre Bibliotheken und Pakete zu liegen haben.
Ich habe Octave nur als simples Beispiel erwähnt, ich habe auch verschiedenen Versionen von gcc gleichzeitig verfügbar, was ja noch wesentlich kritischer wäre für das System beim selbst kompilieren von systemrelevanter Software, wenn man es nicht sauber trennt (das letztere allerdings nur mit openSUSE nicht mit Debian, das Prinzip ist hier aber insofern das gleiche als kompilieren des Kernels mit einer falschen gcc Version recht interessante Effekte haben kann).
Wie aber bereits gesagt, da mir der genaue Anwendungszweck nicht bekannt ist ist das nur ein unverbindlicher Vorschlag von jemandem für den das nach einem typischen Problem für Softwareentwicklung oder Softwaretest klingt und da sind gekapselte lokale Versionen ohne Integration in das Grundsystem (ob Linux, BSD oder was auch immer hier egal) eher Gold wert. Jedenfalls ist das meine persönliche Erfahrung nach 15 Jahren auf dem Gebiet (in der Firma brauch ich das Ganze dann auch noch für verschiedenste Varianten von Java, was allerdings eine hässliche Geschichte ist, da man die proprietäre Version nicht selbst kompilieren kann).
Ohne also zu weit abschweifen zu wollen und auf das ursprüngliche Thema zurückzukommen: Was hier die optimale Lösung ist kann nur anhand des "use cases" entschieden werden und es gibt sicher immer verschiedene gleich gute Lösungen.

[novalix]

Zweifellos alles richtig, was Du sagst; vor allen Dingen das letzte Argument.
Der spezielle "Starter" könnte im Zweifelsfall einfach eine passende Umgebungsvariable für die Entwicklungsumgebung sein, welche nach z.B. "/usr/local/bin/python" zeigt.
Das Beispiel "gcc" bringt mich auf den Gedanken, dass Debian in der Theorie da noch einen Pfeil im Köcher haben könnte: das Alternatives-System.

Code: Alles auswählen

update-alternatives --display cc

zeigt zwar, dass auf meinem Lenny der Symlink auf

Code: Alles auswählen

/usr/bin/gcc

geht, was wiederum selbst ein Symlink auf

Code: Alles auswählen

/usr/bin/gcc4.3

ist. Die Versionen "4.2" und "4.1" sind aber aus historischen Gründen ebenfalls vorhanden.
Bräuchte ich jetzt für ein bestimmtes Kompilat eine der älteren Versionen, wäre es selbstredend weniger günstig den Standard über update-alternatives zu verändern, als einfach für den singulären Kompiliervorgang die entsprechende Umgebungsvariable zu setzen.
Prinzipiell sollte es aber möglich sein, auf diese Art auch unterschiedliche Versionen von Sprachen wie Python oder Perl an den kanonischen Orten über das Paketmanagement zu installieren und das Alternatives-System dafür Sorge tragen zu lassen, die vom System benötigte Version als Standard zu markieren.
Hmm, allerdings müsste man dann für sämtliche verfügbaren Bibliotheks- und Modulversionen ebenfalls Einträge in das System vornehmen.
Sieht mir dann doch nach nem falschen Dampfer aus.

Btw, willkommen im Forum!

Groetjes, niels

[martin1967]

Btw, willkommen im Forum!

Groetjes, niels

Danke, ich habe mir das Forum schon einige Zeit angesehen und finde es vom Lesen her sehr angenehm was die Leute und die Beiträge (Qualität und Tonfall) angeht.
Was das ursprüngliche Thema angeht denke ich nach dem KISS Motto das einfachste ist meistens das beste. Wenn die existierenden Python's aus den Paketquellen nicht reichen, sondern eine ganz spezielle Version benötigt wird (ich hatte doch sowas noch im Kopf, dass man das beim kompilieren angeben kann) unterstützt Python einen alternative install beim make Befehl.

Code: Alles auswählen

make altinstall

Wodurch dann beim Installieren nichts in Konflikt mit der systemweiten Installation geschieht. Man hat halt dann in /usr/bin /usr/local/bin (je nach prefix) die Binaries python2.6, python2.7 usw. und die Python Module werden sowieso in die entsprechenden Unterordner von /usr/lib/pymodules/python2.6 usw. geschickt ohne Konflikte.

Da noch ein kurzer Link dazu, das sollte wirklich die einfachste Lösung sein (abgesehen von der Lösung mit den sowieso über das Paketsystem verfügbaren zu arbeiten, was natürlich noch einfacher ist).

http://makeyjl.blogspot.com/2009/01/bui ... gside.html

Das funktioniert natürlich mit beliebigen Versionen (ich glaube von 2.5 ab aufwärts, für ältere Versionen weiss ich nicht ob es altinstall schon gab).