staging.inyokaproject.org

Hallo,

ein Artikel zu pip, dem "Nachfolger" von easy_install und aktuellen Quasi-Standard zur Installation von Python-Modulen.

Gruß, noisefloor

Hallo,

niemand? Auch gut. Ich hatte eigentlich mit einer Frage zu pip vs. Pakete aus den Quellen gerechnet...

Gruß, noisefloor

Hi noisefloor,

gib doch mal einen Tag zum durchsehen 😛 . Sehr cooler Artikel und schöne Bereicherung fürs Wiki 👍 !

Und da du schon schriebst:

[...] Ich hatte eigentlich mit einer Frage zu pip vs. Pakete aus den Quellen gerechnet...

Ich habe da mal eine Frage: Wie verhält es sich mit pip vs. Pakete aus den Quellen? Ein Abschnitt oder Kommentar dazu wäre hilfreich.

Gruss Lasall

Hallo,

Danke für die Rückfrage 😉. In dem Zuge ist mir auch noch aufgefallen, dass die Fremdsoftware-Warnung fehlt. Ist jetzt analog zu der aus dem Artikel zu easy_install eingebaut.

Gruß, noisefloor

Hallo,

Artikel ist im Wiki.

Gruß, noisefloor

Danke für den Artikel. ☺

noisefloor schrieb:

Ich hatte eigentlich mit einer Frage zu pip vs. Pakete aus den Quellen gerechnet...

Man könnte erwähnen das man solchen Versionskonflikten mit virtualenv aus dem Weg gehen kann. Diese 2 Tools werden ja oft zusammen verwendet.

BTW, virtualenv kann man auch mit Eclipse / PyDev zusammen verwenden (Anleitung). Das gehört aber wieder in einen anderen Artikel.

Hallo,

@senden9: Weißt du, ob pip besser mit virtualenv harmoniert als easy_install? In manchen Dokus / Blogs wird das gute Zusammenspiel hervorgehoben, persönlich fehlt mir da die Erfahrung.

Gruß, noisefloor

pip arbeitet sehr gut mit virtualenv zusammen.

pip is most nutritious when used with virtualenv.

(Quelle: pip Doku) Im gleichen Artikel steht auch das pip dazu geschrieben wurde um easy_install zu verbessen. Ich verwende diese Kombination um Programme die unterschiedliche Versionen der gleichen Bibliothek verwenden gleichzeitig nutzen zu können. Ein weiterer Anwendungszweck ist die Softwareentwicklung - es kann leicht geprüft werden welche Librarys für ein Programm wirklich notwendig sind da durch die Option "--no-site-packages" nur in virtualenv installierte Pakete verwendet werden können.

Edit: Ein Anwendungsbeispiel:

1
2
3

virtualenv name_der_neuen_umgebung  # Eine neue Umgebung erstellen
source name_der_neuen_umgebung/bin/activate  # in die neue Umgebung wechseln. Muss nach dem schließen des Terminals wiederholt werden.
pip install django django-south ipython # Librarys / Anwendungen nach Wunsch in die virtuelle Umgebung installieren

Gut, pip im Wiki zu sehen, aber autsch 😕, die sudo pip-Befehle müssen da ganz schnell raus. Jeder weiß doch, dass man nicht mit APT ins Gehege kommen sollte. Python-Entwicklung mit externen Modulen sollte ausschließlich in einer virtualenv geschehen. Das bietet übrigens eine ganze Latte weiterer Vorteile, von denen schon einige hier angedeutet wurden.

Ein Befehl, um zum Beispiel herauszufinden, welche externen Module man für ein Projekt in einer virtualenv installiert hat, ist: pip freeze -l. Das kann man per Pipe in eine Datei, die für gewöhnlich requirements.txt genannt wird, umleiten. Module in dieser Datei können dann wiederum mit pip install -r requirements.txt installiert werden. Der Workflow sollte jetzt offensichtlich sein.

Weiterhin kann man einfach folgendermaßen Module in ein Verzeichnis in HOME installieren und vermurkst somit nicht sein System: pip install --user <Modul>.

Bitte nehmt doch die sudo-Befehle raus. Ich halte das für unverantwortbar, ich rede mir im IRC regelmäßig das Maul fusselig, wenn mal wieder einer ankommt, der seine Packages so installiert und dadurch import-Probleme hat! Allerdings hab ich grad auch keinen Nerv, den Artikel umzuschreiben.

Hallo,

es ist ein Wiki... das lebt von der Mitarbeit aller! Besonders von der Mitarbeit derer, die tieferes / weitergehendes / ... Wissen haben.

Allerdings hab ich grad auch keinen Nerv, den Artikel umzuschreiben.

Sorry, aber das ist jetzt mal gar kein Grund! In der Zeit, wo du deinen Post schreibst, kann du auch den Artikel editieren. Vorteil: spar dir auch Zeit im IRC, weil du dir dann dort den Wund nicht mehr fusselig reden musst. 😉

Gruß, noisefloor

Hi,

erstmal vielen Dank für diesen Wiki-Artikel. Schön, dass hier auch die Themen Erwähnung finden, die nicht ganz so Mainstream sind. ☺

Ich hätte mal noch eine generelle Frage zu Apt vs. pip. dAnjou schreibt, man solle pip nicht dazu benutzen Python-Module systemweit an Apt vorbei zu installieren, was ich eigentlich genauso sehe. Was wäre also (unter dieser Annahme) das richtige Vorgehen?

1
2
3
4
5
6
7
8
9

# 1. virtualenv Tool systemweit installieren
sudo apt-get install python-virtualenv

# 2. projektspezifische Umgebung anlegen + aktivieren
virtualenv v1
source v1/bin/activate

# 3. benötigte Module mittels pip in die projektspezifische Umgebung installieren
pip install <mod1> <mod2>

Das würde aber heissen, dass ich pip nicht mittels Apt installieren müsste, wie im Artikel beschrieben, da pip per default beim Anlegen einer virtualenv immer mit installiert wird.

Eine andere Variante wäre:

1
2

sudo apt-get install python-pip
sudo pip install virtualenv        # 1x an apt vorbei installiert

Danach weiter, wie oben beschrieben ab Punkt 2.

Ist aus irgendeinem Grund eine Variante der anderen vorzuziehen?

Ändert sich da irgendwas, wenn ich zusätzlich noch virtualenvwrapper benutzen will?

VG, rb

Hallo,

grundsätzlich hat pip mit virtualenv erst Mal nicht wirklich was zu tun - auch, wenn es eine "starke" Beziehung gibt.

Der Fall, dass jemand systemweit Python-Module installieren will (bewusst), ist ja durchaus auch gegeben. Es gibt z.B. ja auch jede Menge Python-Module, die nicht in den Paketquellen sind! pip ist ja keinesfalls alleine an virtualenv gebunden.

Natürlich kann es durchaus vorkommen, dass via pip installierte Module mit Modulen aus den Quellen kollidiert. Das ist aber kein direktes Problem von pip oder apt, sonder das Problem heißt: Nutzer und dessen Systemverwaltung. Sprich, eigenes Thema, eigener Artikel.

Wobei vieles sicherlich entschärft werden können, wenn mehr Nutzer virtualenv nutzen würden. In Pythonkreisen ist es natürlich bekannt, aber gerade bei Python Newbies und "Gelegenheits Python Nutzer" ist das Tool IMHO ziemlich unbekannt.

Gruß, noisefloor

noisefloor schrieb:

Allerdings hab ich grad auch keinen Nerv, den Artikel umzuschreiben.

Sorry, aber das ist jetzt mal gar kein Grund! In der Zeit, wo du deinen Post schreibst, kann du auch den Artikel editieren.

Für einen Artikel müsste ich es aufbereiten und formatieren. Ich tue mich damit immer etwas schwer. Hier kann ich etwas ungeschwollener daherfaseln.

randombits schrieb:

1 2 3 4 5 6 7 8 9

# 1. virtualenv Tool systemweit installieren sudo apt-get install python-virtualenv # 2. projektspezifische Umgebung anlegen + aktivieren virtualenv v1 source v1/bin/activate # 3. benötigte Module mittels pip in die projektspezifische Umgebung installieren pip install <mod1> <mod2>

Ich würde diese Variante unbedingt bevorzugen, eben weil alles dahininstalliert wird, wo es hingehört.

Ändert sich da irgendwas, wenn ich zusätzlich noch virtualenvwrapper benutzen will?

Nein. virtualenvwrapper ist übrigens auch schon etwas länger in den Quellen, vielleicht etwas alt, aber das ist nicht so wichtig, denk ich.

noisefloor schrieb:

Der Fall, dass jemand systemweit Python-Module installieren will (bewusst), ist ja durchaus auch gegeben. Es gibt z.B. ja auch jede Menge Python-Module, die nicht in den Paketquellen sind!

Natürlich kann es durchaus vorkommen, dass via pip installierte Module mit Modulen aus den Quellen kollidiert.

Deswegen kann man ja - wie ich auch schon in meinem vorherigen Beitrag geschrieben habe - Python-Pakete ins Home-Verzeichnis installieren.