Linux Pakete

[Lordkaiser]

Falls es einen Bereich im Forum gibt, der speziell für Linux ist, dann kann das hier auch dorthin geschoben werden, ich habe es grade nicht gefunden.

Zur Frage:
Wie lädt man in Linux Pakete herunter und zwar so, dass man sie dann als Dateien in einem Ordner hat.
Beispiel:
Wenn ich per Befehl sage "sudo apt get install" und z.b. "python3-pip" (ungefähr so müsste der Befehl ja sein),
dann lädt er es zwar auch runter, aber er macht alles automatisch, installiert es und ich weiß nicht, wo es ist.
Vielleicht ist es irgendwo in einem Ordner, aber vielleicht ist das, was im Ordner ist, auch leicht anders als die Pakete, die ich ursprünglich angefragt hatte.

Wie lade ich die Dateien, die für das Installieren von (in dem Fall z.b.) Pip nötig sind, herunter, sodass ich sie z.b. auf einen USB Stick und dann auf einen anderen PC machen könnte, um es dort dann zu installieren?

Also das "Paket" herunterladen wie einen "Installer"/"Setup" in Windows.

Weiteres Beispiel neben Python3, -pip, -pygame wären die Video-/Audiocodecs.
Linux (Mint), nachdem es ganz frisch installiert war, hat mich direkt gefragt, ob ich diese installieren wolle.
Habe es dann mit dem Internet verbunden und das gemacht. Hat auch funktioniert.
Aber die würde ich auch gern separat als Installer-Datei haben.

[demonaz]

für den debian-Fall: https://www.debian.org/distrib/packages#search_packages
-> https://packages.debian.org/bullseye/python3-pip
-> https://packages.debian.org/bullseye...3-pip/download

Falls Sie Debian auf Ihrem Rechner einsetzen, wird nachdrücklich empfohlen, einen Paket-Manager wie Aptitude oder Synaptic zum Herunterladen und Installieren von Paketen zu benutzen und nicht diese Website.

Das Paket allein reicht dir ja nicht, du brauchst dann auch die ganzen anderen Pakete, von denen dein gesuchtes Paket abhängt. kann man machen:

apt --download-only install python3-pip

ls /var/cache/apt/archives/
libexpat1-dev_2.4.7-1ubuntu0.2_amd64.deb      libpython3-dev_3.10.6-1~22.04_amd64.deb  python3.10-dev_3.10.6-1~22.04.2_amd64.deb  python3-lib2to3_3.10.6-1~22.04_all.deb                python3-wheel_0.37.1-2ubuntu0.22.04.1_all.deb
libjs-sphinxdoc_4.3.2-1_all.deb               lock                                     python3-dev_3.10.6-1~22.04_amd64.deb       python3-pip_22.0.2+dfsg-1ubuntu0.2_all.deb            zlib1g-dev_1%3a1.2.11.dfsg-2ubuntu9.2_amd64.deb
libpython3.10-dev_3.10.6-1~22.04.2_amd64.deb  partial                                  python3-distutils_3.10.6-1~22.04_all.deb   python3-setuptools_59.6.0-1.2ubuntu0.22.04.1_all.deb

Die kannst du dann kopieren. Problem: python3 war bei meinem Test schon installiert, das lädt apt dann schon mal nicht runter - das musst du dann genauso machen, undsoweiterundsoweiter. Oder dein Zielrechner hat das schon installiert. Sehr fehleranfällig. Soll python3-pip auf einem offline-rechner installiert werden? und via "pip install xxx' will man ja ggf weitere python-pakete installieren. So ganz erschließt sich mir das ganze nicht...

tl;dr: ich würds normalerweise nicht so machen

[Shakka]

Oder man verwendet sowas wie Flatpak.
Je nach Paket sind da alle Abhängigkeiten mit drin.

[Ramkhamhaeng]

Man sollte auch unterscheiden zwischen Python/python-pip und den Python-Modulen, die man mit den beiden ersten Sachen installieren will. Python und Pip sollte man am besten dem System überlassen. Den Rest kann man wie gewünscht an einer manuell festlegbaren Stelle sammeln.

echo "Erstelle 'virtuelle Umgebung' für Python-Pakete"
python3 -m venv test_venv

echo "Aktiviere virtuelle Umgebung"
source test_venv/bin/activate

echo "Installiere nun per Pip ein Paket (psutil ist nur ein Beispiel)"
python3 -m pip install psutil

Danach befindet sich das installierte Paket in „test_venv/lib“ und man hat bei der Installation nichts am eigentlichen System geändert.
Wichtig ist, dass man vor der Benutzung die entsprechende virtuelle Umgebung erst aktivieren muss. Meistens legt man sich
für jedes Programm, dass man entwickeln will, eine eigene an.

Das Thema automatische Installation von Abhängigkeiten bei Python-Paketen lasse ich mal weg, um es nicht noch komplizierter zu machen.

[DerMonte]

Oder man verwendet sowas wie Flatpak.
Je nach Paket sind da alle Abhängigkeiten mit drin.

Oder wenn es ein Ubuntu ist, kann man auch Snap benutzen

[Flunky]

Man sollte auch unterscheiden zwischen Python/python-pip und den Python-Modulen, die man mit den beiden ersten Sachen installieren will. Python und Pip sollte man am besten dem System überlassen. Den Rest kann man wie gewünscht an einer manuell festlegbaren Stelle sammeln.

echo "Erstelle 'virtuelle Umgebung' für Python-Pakete"
python3 -m venv test_venv

echo "Aktiviere virtuelle Umgebung"
source test_venv/bin/activate

echo "Installiere nun per Pip ein Paket (psutil ist nur ein Beispiel)"
python3 -m pip install psutil

Danach befindet sich das installierte Paket in „test_venv/lib“ und man hat bei der Installation nichts am eigentlichen System geändert.
Wichtig ist, dass man vor der Benutzung die entsprechende virtuelle Umgebung erst aktivieren muss. Meistens legt man sich
für jedes Programm, dass man entwickeln will, eine eigene an.

Das Thema automatische Installation von Abhängigkeiten bei Python-Paketen lasse ich mal weg, um es nicht noch komplizierter zu machen.

Da mal einsteigend: venv oder Conda?

[Lordkaiser]

Da mal einsteigend: venv oder Conda?

Entschuldigung, ist diese Frage an mich gerichtet gewesen? Ich verstehe sie nicht einmal. Ich bin ein Noob.

[Flunky]

Ne, an die Experten hier.

Python hat, wenn man mehrere Projekte parallel bearbeitet, oft Konflikte zwischen irgendwelchen Bibliotheken. Deshalb kann man, wie Ramk gezeigt hat, virtuelle Umgebungen aufmachen, die sich nicht gegenseitig stören. Conda/Anaconda ist ein anderer Weg zu virtuellen Umgebungen, den ich meist nutze. venv kannte ich noch gar nicht. Ich würde gerne wissen, wo die Vor- und Nachteile der beiden Wege liegen.
Bei Conda nervt mich z.B., dass man immer von 0 anfängt und nicht auf einem konfigurieren Default.

[Ramkhamhaeng]

Ich bin auch zu wenig Experte, da ich Anaconda nur einmal genutzt habe. Grundsätzlich würde ich beides nicht auf einem Abstraktionslevel anordnen. Venv ist eine abgespeckte Version von virtualenv, die den Vorteil besitzt, dass sie seit Python 3.3 zu den Standardpaketen gehört. Damit eignet sich venv besonders gut für Minimalbeispiele oder kleine Projekte ohne besondere Abhängigkeiten.

In meinem Beispiel mit 'venv' sieht man auch, dass es nicht zum Installieren von Pakten gedacht ist. Das wird dann von 'pip' übernommen.

Conda/Anaconda ist dagegen eher ein komplettes Ökosystem/vollständige Paketverwaltung. Es erstellt virtuelle Umgebungen, installiert Pakete und Abhängigkeiten und man kann auch selber Pakete erstellen. ( Also Dinge für die man die Python-Standardpaket venv, pip und wheel verwenden könnte.)
Damit würde ich statt venv eher Poetry vergleichen. Das hat Zulan mal erwähnt und ich habe es jetzt auch zweimal verwendet. Ich fand die Komplexität beim Erstellen eines Pakets nimmt ab und man ist am Anfang nicht gleich von der Erstkonfiguration abgeschreckt.

Bei Github hat Poetry sogar 10x so viele Likes wie Conda. Bei der Anzahl der Contributern und den offenen Issues sind sie auf ähnlichem Niveau.

Am Anfang (@Lordkaiser) braucht man sich damit aber nicht beschäftigen. Eigene Virtuelle Umgebung erstellen und dann mit 'pip' Pakete installieren sollte da vollständig ausreichen

[Zulan]

Also venv kümmert sich nur um die Isolation verschiedener Python-Umgebungen. Conda macht, wie schon erwähnt, viel mehr als das, aber auch isolation. Klassisch ist conda stark im Bereich data science um komplexe Abhänigkeiten von nicht-pure-Python-Bibliotheken zu verwalten. Aber ehrlich gesagt, ist mir das noch nie untergekommen, dass ich das wirklich dazu gebraucht hätte. Aus praktischer Sicht kann conda, insbesondere miniconda, aber z.B. interessant sein, um Python-Versionen selbst mit zu verwalten. Im Gegensatz zu venv, das auf System-Python-Versionen aufbaut, kann conda eigene Python-Versionen mitbringen. Wenn man also auf einem veralteten LTS System eine aktuelle Python-Version braucht, kann das interessant sein.

Poetry wiederum kümmert sich um dependency management und packaging (vergleichbar eher mit setup.py / requirements.txt / pip / pipenv). Zur installation selbst, nutzt poetry under the hood auch virtualenv. Der große Vorteil von poetry für dependency management von Anwendungen ist aus meiner Sicht, dass man die manuelle Abhängigkeitsdefinitionen flexibel hält (mit entsprechenden Versionsranges), aber durch lockfiles trotzdem reproduzierbar gleiche Installationen bekommt (wie mit fest gepinnten Versionen und zudem mit hashes). Das kann pipenv auch, poetry ist aber um ein vielfaches schneller.

Grundsätzlich ist das auch alles ziemlich interoperabel. Man kann z.B. die virtualenvs von poetry auch einfach aktivieren. Und unter conda kann man auch relativ flexibel mit pip arbeiten...

[Flunky]

Conda+pip funktioniert nur, wenn man danach nichts mehr über conda installieren will und auf das automatische dependency management verzichtet. Klar, wenn man vorher weiß, was gebraucht wird... aber (#datascience) komm ich oft während des Projekts auf irgendwelche Pakete, die irgendwas einfacher machen würden. Dann geht es oft nur, die Paketliste zu exportieren und das conda env neu aufzusetzen.