Module unter Linux installieren

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

Hallo zusammen!

Es gibt ja unzählige Linux Distributionen da draußen; und ebenso viele Paketmanager und dazugehörige Pakete. Manche bieten Python Module wie numpy, requests, etc. als separates Paket des Paketmanagers an, andere nicht, wieder andere nur bestimmte Module und von Versionen fange ich garnicht erst an.

Da sieht es oft einfacher (weil: einheitlicher) aus, einfach die benötigten Module per pip zu installieren: Der Befehl ist überall gleich, lässt den Paketmanager aussen vor und holt praktischerweise auch immer die letzte verfügbare Version.

Jetzt die Frage: Ist das denn im Sinne von "nicht mit Paketmanager XY aneinander geraten" empfehlenswert pip für globale Modulinstallationen auf Systemen mit eigenen Paketen für die Module zu vewenden?

Was passiert z.B. in folgenden Fällen?

Man installiert ein Modul über pip auf einem System, ...
  1. ... welches das Modul noch nicht als Paket installiert hat, jedoch anschließend versucht jemand das Paket zu installieren - kollidieren die Dateien von der pip Installation und des Systems?
  2. ... welches eine ältere Version des Modules bereits über seinen Paketmanager installiert hat? Existiert das Modul anschließend 2x auf dem System? Wie wird bei einem import entschieden, welches verwendet wird?
  3. ... welches eine ältere Version des Modules bereits über seinen Paketmanager installiert hat; zu einem späteren Zeitpunkt wird das Paket jedoch aktualisiert (weil z.B. Rolling Release). Was passiert nun mit dem (nun älteren) per pip installiertem Modul?
Danke für die Antworten!

PS:
Zumindest auf einem Arch Linux habe ich den ersten Fall eben mal nachgestellt: Das scheint zu einem Dateikonflikt zu führen, weil Dateien, welche das Paket anlegen möchte, bereits durch pip existieren:

Code: Alles auswählen

[root@0b42682d575648488048566616516654 sbin]# pip3 install requests
Collecting requests
  Downloading requests-2.9.1-py2.py3-none-any.whl (501kB)
    100% |################################| 503kB 109kB/s 
Installing collected packages: requests
Successfully installed requests-2.9.1
[root@0b42682d575648488048566616516654 sbin]# pacman -S python-requests python2-requests
resolving dependencies...
looking for conflicting packages...

Packages (6) python-chardet-2.3.0-2  python-urllib3-1.14-1  python2-chardet-2.3.0-2  python2-urllib3-1.14-1  python-requests-2.9.1-1  python2-requests-2.9.1-1

Total Download Size:   0.71 MiB
Total Installed Size:  5.39 MiB

:: Proceed with installation? [Y/n] Y
:: Retrieving packages...
 python-urllib3-1.14-1-any                                                                                           100.0 KiB   123K/s 00:01 [#######################################################################################] 100%
 python-chardet-2.3.0-2-any                                                                                          196.3 KiB  1636K/s 00:00 [#######################################################################################] 100%
 python-requests-2.9.1-1-any                                                                                          79.4 KiB  1588K/s 00:00 [#######################################################################################] 100%
 python2-urllib3-1.14-1-any                                                                                           99.4 KiB  1657K/s 00:00 [#######################################################################################] 100%
 python2-chardet-2.3.0-2-any                                                                                         179.6 KiB  1996K/s 00:00 [#######################################################################################] 100%
 python2-requests-2.9.1-1-any                                                                                         76.5 KiB  1275K/s 00:00 [#######################################################################################] 100%
(6/6) checking keys in keyring                                                                                                                [#######################################################################################] 100%
(6/6) checking package integrity                                                                                                              [#######################################################################################] 100%
(6/6) loading package files                                                                                                                   [#######################################################################################] 100%
(6/6) checking for file conflicts                                                                                                             [#######################################################################################] 100%
error: failed to commit transaction (conflicting files)
python-requests: /usr/lib/python3.5/site-packages/requests/__init__.py exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/__pycache__/__init__.cpython-35.pyc exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/__pycache__/adapters.cpython-35.pyc exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/__pycache__/api.cpython-35.pyc exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/__pycache__/auth.cpython-35.pyc exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/__pycache__/certs.cpython-35.pyc exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/__pycache__/compat.cpython-35.pyc exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/__pycache__/cookies.cpython-35.pyc exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/__pycache__/exceptions.cpython-35.pyc exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/__pycache__/hooks.cpython-35.pyc exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/__pycache__/models.cpython-35.pyc exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/__pycache__/sessions.cpython-35.pyc exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/__pycache__/status_codes.cpython-35.pyc exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/__pycache__/structures.cpython-35.pyc exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/__pycache__/utils.cpython-35.pyc exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/adapters.py exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/api.py exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/auth.py exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/certs.py exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/compat.py exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/cookies.py exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/exceptions.py exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/hooks.py exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/models.py exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/packages/__init__.py exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/packages/__pycache__/__init__.cpython-35.pyc exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/sessions.py exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/status_codes.py exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/structures.py exists in filesystem
python-requests: /usr/lib/python3.5/site-packages/requests/utils.py exists in filesystem
Errors occurred, no packages were upgraded.
[root@0b42682d575648488048566616516654 sbin]#
... das ist ja eher eine nicht wünschenswerte Situation ... :/
Ein nicht Python-affiner Sysadmin sieht nur "W00t!?! Wer schreibt da in für den Paketmanager reservierten Dateisystembereichen rum??" und rennt mit dem Ledergürtel durch den Flur ... O.o
Benutzeravatar
pillmuncher
User
Beiträge: 1484
Registriert: Samstag 21. März 2009, 22:59
Wohnort: Pfaffenwinkel

Meine Regel dazu: Die Pythonmodule, die von Pythonprogrammen aus Paketen der Linux-Distribution verwendet werden, werden mit apt-get oder synaptic oder welchem Paketmanager auch immer installiert. Normalerweise geschieht das automatisch, wenn ich ein Paket installiere, das sie vewendet. Wenn ich ein eigenes Pythonprogramm schreibe, erstelle ich mit virtualenv eine Umgebung, in der ich die Pythonmodule via pip installiere, die ich dafür brauche.
In specifications, Murphy's Law supersedes Ohm's.
BlackJack

@Judge: Wobei zumindest das Paketmanagerbeispiel komisch ist. Ich würde erwarten, das der Paketmanager nach `/usr/lib/…` & Co installiert und das selbst installiertes, zum Beispiel mit `pip` in `/usr/local/lib/…` & Co landet. Ist bei mir unter Ubuntu jedenfalls so. Das heisst wenn ich systemweit etwas installiere, sollte sich das nicht mit der Paketverwaltung um Dateien streiten. Zumindest nicht auf dieser Ebene. Wo es dann natürlich Probleme geben kann ist wenn andere Systempakete auf einer eventuell älteren Abhängigkeit bestehen und stattdessen das aus `/usr/local/…` bekommen und damit dann nicht mehr laufen. Darum installiere ich auf diese Weise in der Regel eher Sachen die es nicht als Paket gibt. Ansonsten wie pillmuncher schon anmerkte: `virtualenv`.
Benutzeravatar
Judge
User
Beiträge: 129
Registriert: Mittwoch 13. Juni 2012, 22:27
Wohnort: Ratingen
Kontaktdaten:

BlackJack hat geschrieben:@Judge: Wobei zumindest das Paketmanagerbeispiel komisch ist. Ich würde erwarten, das der Paketmanager nach `/usr/lib/…` & Co installiert und das selbst installiertes, zum Beispiel mit `pip` in `/usr/local/lib/…` & Co landet. Ist bei mir unter Ubuntu jedenfalls so. Das heisst wenn ich systemweit etwas installiere, sollte sich das nicht mit der Paketverwaltung um Dateien streiten. Zumindest nicht auf dieser Ebene. Wo es dann natürlich Probleme geben kann ist wenn andere Systempakete auf einer eventuell älteren Abhängigkeit bestehen und stattdessen das aus `/usr/local/…` bekommen und damit dann nicht mehr laufen. Darum installiere ich auf diese Weise in der Regel eher Sachen die es nicht als Paket gibt. Ansonsten wie pillmuncher schon anmerkte: `virtualenv`.
Hi BlackJack,

sorry für's späte Antworten; Ostern und so ...
Genau das, was Du beschreibst, versucht der Paketmanager (von ArchLinux in diesem Fall) ja auch: Erst installiere ich "requests" per pip - kein Problem. Danach nochmal das entsprechende ArchLinux Paket; Pacman (der ArchLinux Paketmanager) findet dann schon Dateien in "seinem" Zielverzeichnis (welches, wie Du richtig erwartest, /usr/lib/ ist) und meldet den gezeigten Fehler.

pip installiert hier standardmäßig nicht nach /usr/local/lib (was ja OK wäre: /usr/local ist ja genau für sowas da), sondern nach /usr/lib .

Heißt das, das ich pip irgendwie beibringen muss standardmäßig nach /usr/local zu installieren? (Wahrscheinlich dann über /etc/pip.conf?)
(Wie) Muss ich dann andere Python-Elemente (interpreter, setuptools, ...) auch noch konfigurieren, damit diese die durch pip installierten Module in diesem neuen Pfad finden?
Benutzeravatar
snafu
User
Beiträge: 6738
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

@Judge
Mach dir das Leben nicht unnötig schwer. Lies dich in `virtualenv` ein und nutze lieber diese Lösung. Das haben auch schon viele vor dir so gemacht und es hat sich bewährt.

Wenn du anfängst, an der Konfiguration des Interpreters herumzuwerkeln, dann kann es schnell passieren, dass wichtige Python-Module, die von deinem System benötigt werden, danach überhaupt nicht mehr bzw in einer falschen Version gefunden werden - und das wäre gar nicht gut.
Benutzeravatar
Judge
User
Beiträge: 129
Registriert: Mittwoch 13. Juni 2012, 22:27
Wohnort: Ratingen
Kontaktdaten:

snafu hat geschrieben:@Judge
Mach dir das Leben nicht unnötig schwer. Lies dich in `virtualenv` ein und nutze lieber diese Lösung. Das haben auch schon viele vor dir so gemacht und es hat sich bewährt.

Wenn du anfängst, an der Konfiguration des Interpreters herumzuwerkeln, dann kann es schnell passieren, dass wichtige Python-Module, die von deinem System benötigt werden, danach überhaupt nicht mehr bzw in einer falschen Version gefunden werden - und das wäre gar nicht gut.
Auch wahr.

Für mich als Neuling heißt das, das man auf Hosts, die Python Programme ausführen können sollen, immer wenigstens folgende Requirements hat:
  • Python Interpreter
  • pip + setuptools
  • virtualenv
Alles weitere dann in der virtuellen Umgebung; stimmt das soweit, damit man ein abgeschottetes virtualenv samt allem notwendigen um Module dorthin nachholen zu können hat oder vergesse ich was?
BlackJack

@Judge: Bei aktuellen CPython-Versionen (also auch bei 2.7.x) sind die ersten beiden Punkte eigentlich einer, denn PIP wird mittlerweile gleich mit ausgeliefert. Eventuell muss man es aktualisieren.
Benutzeravatar
snafu
User
Beiträge: 6738
Registriert: Donnerstag 21. Februar 2008, 17:31
Wohnort: Gelsenkirchen

@Judge
Also ich sehe `virtualenv` nicht immer als Pflicht an. Ich nutze das persönlich nur dann, wenn Abhängigkeiten von dem selben Paket aber in unterschiedlichen Versionen bestehen oder wenn ich unter Linux etwas bewusst an der Paketverwaltung der Distribution vorbei installiere.
Antworten