Mehrere Pythons in produktiver Umgebung

Probleme bei der Installation?
Benutzeravatar
Judge
User
Beiträge: 89
Registriert: Mittwoch 13. Juni 2012, 22:27
Wohnort: Ratingen
Kontaktdaten:

Mehrere Pythons in produktiver Umgebung

Beitragvon Judge » Samstag 13. Mai 2017, 22:29

Hallo Leute,

Ich arbeite in einer Umgebung, wo sehr viele Python-Shellapplikationen auf einem zentralen CentOS Linux "Management"-Host von dutzenden von Leuten täglich verwendet werden, die jedoch Python-Technisch zum großen Teil als "Anwender" einzustufen sind. Es können zwar viele Python aber eben nicht alle; aus diesem und anderen Gründen ist unser Anspruch, dass ein Python-Script ohne spezielle Vorbereitung nur anhand der Shebang aufrufbar ist.

Derzeit befindet sich auf diesem Server nur ein Python 2.6.6 . Ohne das "was ist besser: 3 oder 2?" - Fass hier mal wieder aufmachen zu wollen: Ich hätte gerne drei Python Versionen auf dem System, zwischen dem sich der Entwickler entscheiden können soll:
  • aktuell verwendete 2.6.6 (einfach, weil diese aus dem Repo des stark verwurzelten Systems kommt und da inzwischen etliche Sonderlocken eingeflossen sind, als Kompatibilitätssicherung/Fallback)
  • die aktuell neueste 2.7.13
  • die aktuellste 3.6.1 für die zukunftssichere Entwicklung neuer Skripte auch nach 2020

Jetzt überlege ich, wie man das am besten realisieren kann.
Da man einen Tanker nur schwer wendet, würde ich die bisher verwendete Version 2.6.6 weiterhin als "Standard-Python" gesetzt lassen (also auch: /usr/bin/python).
Die anderen beiden würde ich gerne geneigten Entwicklern zusätzlich zur Verfügung stellen. Es ist jedoch oberste Priorität, das diese in keiner Form das bisherige Verhalten stören. Auch darf es für den Anwender keine zusätzlichen Schritte geben, wie z.B. mit anaconda o.ä. erstmal ein Environment aktivieren zu müssen oder ähnliches. Auch darf eine Modulinstallation aus dem CentOS Repo die manuell installierten Versionen nicht "stören"; anders herum darf eine Installation von Modulen aus etwa dem PIP dieser neuen Versionen die ältere 2.6.6 durcheinander bringen.
Ich hätte gerne einfach nur die 2.7.13 und 3.6.1 irgendwo liegen (etwa: /opt/python_2.7.13 und /opt/python_3.6.1). Entwickler sollen nach möglichkeit nur über die Shebang definieren müssen welches Python sie gerne verwenden würden und feddich. Die Anwender sollen, egal welches Python zugrunde liegt, immer jedes Script einfach per "./script.py" o.ä. aufrufen können; weder ein Environment-Switch noch ein vorangestellter Interpreter (z.B. /opt/python_3.6.1/bin/python script.py) darf notwendig sein.

/usr/bin/python und /usr/bin/python2 blieben dabei Python 2.6.6
/usr/bin/python27 wäre - logisch - Python 2.7.13
/usr/bin/python3 wäre Python 3.6.1

Stelle ich mir das alles zu einfach vor, oder geht das wirklich so einfach?
Gibt es irgendwelche Stolperfallen, wo sich mehrere verschiedene Versionen auf einem System in die Quere kommen?
Was halt auf garkeinen Fall passieren darf ist, das die bisherigen Scripte in Ihrer Funktionsfähigkeit beeinflusst werden oder das es gar zu einfach ist die Interpreter durcheinander zu bringen (weil man z.B. dauernd verwechselt das ein Modul eigentlich für 3.6.1 installiert wurde, nun wurde es jedoch blöderweise in 2.6.6 aktualisiert oder anders herum).

LG
Sirius3
User
Beiträge: 6007
Registriert: Sonntag 21. Oktober 2012, 17:20

Re: Mehrere Pythons in produktiver Umgebung

Beitragvon Sirius3 » Samstag 13. Mai 2017, 22:47

@Judge: es kann halt zu Problemen kommen, wenn man Pakete installieren will oder die falschen Environment-Variablen gesetzt hat. Ansonsten sollte das kein Problem sein.
Benutzeravatar
BlackJack
Moderator
Beiträge: 32712
Registriert: Dienstag 25. Januar 2005, 23:29
Wohnort: Berlin
Kontaktdaten:

Re: Mehrere Pythons in produktiver Umgebung

Beitragvon BlackJack » Samstag 13. Mai 2017, 23:09

@Judge: Was ich auf jeden Fall machen würde ist sämtliche direkt ausführbaren ``pip``\s zu deinstallieren und/oder zu verbieten. Das mache ich selbst bei Systemen die ich nur selbst verwende. Ich führe ``pip`` immer als Modul mit dem jeweiligen Python aus, dann weiss man auch ganz sicher für welche Python-Installation man das gerade macht.
“XML combines all the inefficiency of text-based formats with most of the unreadability of binary formats :-)” — Oren Tirosh, c.l.p, 2002
nezzcarth
User
Beiträge: 364
Registriert: Samstag 16. April 2011, 12:47

Re: Mehrere Pythons in produktiver Umgebung

Beitragvon nezzcarth » Samstag 13. Mai 2017, 23:24

BlackJack hat geschrieben:Ich führe ``pip`` immer als Modul mit dem jeweiligen Python aus, dann weiss man auch ganz sicher für welche Python-Installation man das gerade macht.

Zumindest bei mir gibt es in /usr/bin/ neben reinem pip auch welche mit nachgestellter Versionsnummer (etwa 'pip3.6'). Ist die Variante, die du vorschlägst vom Effekt her gleich, oder ist das noch einmal anders?
Benutzeravatar
BlackJack
Moderator
Beiträge: 32712
Registriert: Dienstag 25. Januar 2005, 23:29
Wohnort: Berlin
Kontaktdaten:

Re: Mehrere Pythons in produktiver Umgebung

Beitragvon BlackJack » Samstag 13. Mai 2017, 23:38

@nezzcarth: Das Problem dabei ist das reine ``pip`` und ``pip2`` und ``pip3``. Es ist halt nicht klar für welche Version genau das jeweils ist und wenn man mehrere Python-Versionen installiert hat, dann kann sich die Python-Installation auf die sich diese Programme beziehen nach jedem ``pip install -U pip`` ändern. Während es immer eindeutig ist, wenn man exakt das Python für das man installieren möchte aufruft und das `pip`-Modul ausführen lässt.
“XML combines all the inefficiency of text-based formats with most of the unreadability of binary formats :-)” — Oren Tirosh, c.l.p, 2002
Benutzeravatar
Judge
User
Beiträge: 89
Registriert: Mittwoch 13. Juni 2012, 22:27
Wohnort: Ratingen
Kontaktdaten:

Re: Mehrere Pythons in produktiver Umgebung

Beitragvon Judge » Montag 15. Mai 2017, 07:43

Danke für Eure Meinungen und guten Tipps!
Benutzeravatar
Judge
User
Beiträge: 89
Registriert: Mittwoch 13. Juni 2012, 22:27
Wohnort: Ratingen
Kontaktdaten:

Re: Mehrere Pythons in produktiver Umgebung

Beitragvon Judge » Montag 29. Mai 2017, 21:46

BlackJack hat geschrieben:@nezzcarth: Das Problem dabei ist das reine ``pip`` und ``pip2`` und ``pip3``. Es ist halt nicht klar für welche Version genau das jeweils ist und wenn man mehrere Python-Versionen installiert hat, dann kann sich die Python-Installation auf die sich diese Programme beziehen nach jedem ``pip install -U pip`` ändern. Während es immer eindeutig ist, wenn man exakt das Python für das man installieren möchte aufruft und das `pip`-Modul ausführen lässt.


Das scheint aber ein Tipp für Python >=2.7 zu sein:

Code: Alles auswählen

$ source activate py27
(py27) $ python -V
Python 2.7.13 :: Continuum Analytics, Inc.
(py27) $ python -m pip -V
pip 9.0.1 from /home/judge/.local/lib/python2.7/site-packages (python 2.7)
(py27) $ source deactivate py27
$ source activate py26
(py26) $ python -V
Python 2.6.9 :: Continuum Analytics, Inc.
(py26) $ python -m pip -V
/home/judge/.conda/envs/py26/bin/python: pip is a package and cannot be directly executed
(py26) $

Zurück zu „Installation/Konfigurieren“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder