Fragen zum Python-Paketmanagement und Pycharm

[mephisto-online]

Hallo zusammen,

Beim einem neuerlichen Rolling-Release-Upgrade meines Manjaro/Arch-Betriebssystems wurde Python von Release 3.3 auf 3.4 upgedatet. Danach meldete PyCharm nach dem Start, dass der Interpreter meines Projekts (Python3.3) nicht konfiguriert sei. Nachdem ich dann den neuen 3.4er angemeldet habe, sind nicht mehr alle Pakete der vorherigen Version 3.3 verfügbar, die sich aber noch in "/usr/lib/python33/site-packages" befinden.

Jetzt möchte ich das aber nicht nur einfach hinfummeln sondern endlich mal wissen, wie ich es denn in Zukunft mit den Python-Paketen sinnvollerweise handhaben sollte.

Was mich bei Python schon von Anfang an irritiert hat, dass Python-Pakete auf verschiedene Arten installiert werden können:

1. über die Repos des Betriebssystems, was den Vorteil hat, dass neue, freigegebene Versionen automatisch upgedatet werden.
2. über (sudo) "pip install"
3. über setup.py eines heruntergeladenen Pakets
4. über PyCharm

Wenn man diese Methoden mischt, bekommt man offensichtlich Probleme, wie ich schon schmerzlich erfahren musste. Erst, nachdem ich konsequent alle Pakete mit PyCharm (nach)installiert hatte, konnte ich problemlos (mit PyCharm) arbeiten.

Nun geht aber wieder gar nichts mehr und ich würde gerne einiges wissen, um es in Zukunft "richtig" zu machen:

- Wie installiert Pycharm die Pakete ?
- Warum sehe ich mit "pip list" weniger Pakete als in den PyCharm-Settings
- Sollte man die Installation von Paketen über die BS-Repos vielleicht generell meiden ?
- Wie gehe ich vor, wenn PyCharm ein Paket, was ich benötige, nicht kennt ?

Grüße
m-o

[pillmuncher]

Evtl. möchtest du dich über virtualenv informieren.

[mephisto-online]

Mir ist schon klar, was virtualenv ist, aber was macht das für einen Unterschied, ob die Pakete in Systempfaden oder in einer virtuellen Laufzeit-Umgebung lokalisiert sind ? Im Moment stellt sich das für mich so dar, dass der Einsatz von virtualenv lediglich den Aufwand erhöht.

Welche Vorteile kann ich mir durch den Einsatz von virtualenv versprechen und welche Nachteile handele ich mir damit ein ? Und welche meiner oben gestellten Fragen wären damit vielleicht aus der Welt ? Das kann ich als Python-Neuling nicht so ganz einschätzen und diese Punkte konnte ich bislang online auch noch nicht ausreichend klären.

Ok, ich kann mir mehrere solcher Umgebungen schaffen, aber was bringt mir das ? Nach Windows oder Android mitnehmen kann ich sie ja auch nicht, sonst wäre es wirklich ein Vorteil.

[pillmuncher]

Wie das Zusammenspiel mit PyCharm ist, kann ich nicht beurteilen, da ich ausschließlich vim verwende. Ansonsten:

Nachdem ich dann den neuen 3.4er angemeldet habe, sind nicht mehr alle Pakete der vorherigen Version 3.3 verfügbar, die sich aber noch in "/usr/lib/python33/site-packages" befinden.

Wenn du virtualenv verwendest, dann werden mittels pip install ... alle Packages in das site-packages Verzeichnis des virtuellen Environments installiert. Falls du dann ein Upgrade von Python33 auf Python34 vornimmst, ändert sich nichts am virtuellen Environment und alle diese Packages bleiben für dein Projekt benutzbar, sofern mit der neuen Python-Version kompatibel. Von 3.3 auf 3.4 sollte das kein Problem sein.

Das virtuelle Environment solltgest du nicht für Deployment/User Installation etc. missbrauchen. Es ist ja nicht gesagt, dass alle dort installierten Packages mit ausgeliefert werden sollen. Was sollte ein Webserver etwa mit Rope anfangen? Statt dessen einfach über einen der verschiedenen möglichen Wege eine setup.py erstellen, die alles installiert, was dein Projekt benötigt.

[mephisto-online]

Mit virtualenv habe ich also die site-packages nur noch einmal auf dem Rechner. Steuern kann ich das Ganze per Umgebungsvariable und ini-File.

Kann man mit virtualenv die System-Python-Umgebung und die Enwicklungsumgebung voneinander trennen ?

[pillmuncher]

Mit virtualenv habe ich also die site-packages nur noch einmal auf dem Rechner. Steuern kann ich das Ganze per Umgebungsvariable und ini-File.

Äh ... nein. Normalerweise hat jedes virtuelle Environment ein eigenes site-packages. Dazu gibt es die jeweiligen site-packages der im System installierten Python-Versionen. Aktiviert wird ein virtuelles Environment mittels ~/.virtualenvs/<project>/Scripts/activate (sofern deine virtuellen Environments unter ~/.virtualenvs/ leben).

Kann man mit virtualenv die System-Python-Umgebung und die Enwicklungsumgebung voneinander trennen ?

Das ist geradezu der Sinn von virtualenv.

Am besten, du probierst es einfach mal aus. Was virtualenv tut erschließt sich vielleicht am ehesten, wenn man etwas damit herumspielt. Schau dir auch zusätzlich virtualenvwrapper an.

[mephisto-online]

ThankX ! Werde es auf jeden Fall mal probieren, jetzt, wo ich in etwa weiß, was da passiert.

Aktiviert wird ein virtuelles Environment mittels ~/.virtualenvs/<project>/Scripts/activate (sofern deine virtuellen Environments unter ~/.virtualenvs/ leben).

Hab ich gelesen. Aber für was genau gilt denn dann diese Aktivierung ? Systemweit für alle Python-Programme/-Skripte ? Nur für einen bestimmten Interpreter ? Nur für bestimmte Programme ?

[BlackJack]

@mephisto-online: Das gilt für den Prozess der das aktiviert hat, also wenn man das in der Shell macht, für *diese* Shell. Systemweit würde den Zweck, dass man für jedes Projekt die exakt passenden Packages in den passenden Version verwenden kann, unterlaufen.

[mephisto-online]

@BlackJack
Ok, für einen Prozess ! Dann ist mir das jetzt einigermassen klar. Wüde ja anders wirklich auch keinen rechten Sinn machen. Man muss dann wohl ein in einer virtualenv entwickeltes Programm mit einem Skript starten.

Werde mal damit rumspielen. Die Sache gefällt mir, weil man damit die im System installierten Pakete auf die für installierte Python-Programme benötigten reduzieren kann.

Danke !