Nächste: guix pack
aufrufen, Vorige: guix shell
aufrufen, Nach oben: Entwicklung [Inhalt][Index]
guix environment
aufrufenDer Zweck von guix environment
ist es, dass Sie
Entwicklungsumgebungen leicht anlegen können.
Diese Funktionalität wird demnächst verschwinden: Der Befehl
guix environment
gilt als veraltet. Stattdessen sollten Sieguix shell
benutzen, was einen ähnlichen Zweck erfüllt, aber leichter zu benutzen ist. Sieheguix shell
aufrufen.Veraltet heißt,
guix environment
wird letztendlich entfernt, aber das Guix-Projekt wird gewährleisten, dassguix environment
bis zum 1. Mai 2023 verfügbar bleibt. Reden Sie mit uns unter guix-devel@gnu.org, wenn Sie dabei mitdiskutieren möchten!
Die allgemeine Syntax lautet:
guix environment Optionen Paket…
Folgendes Beispiel zeigt, wie eine neue Shell gestartet wird, auf der alles für die Entwicklung von GNU Guile eingerichtet ist:
guix environment guile
Wenn benötigte Abhängigkeiten noch nicht erstellt worden sind, wird
guix environment
sie automatisch erstellen lassen. Die Umgebung
der neuen Shell ist eine ergänzte Version der Umgebung, in der guix
environment
ausgeführt wurde. Sie enthält neben den existierenden
Umgebungsvariablen auch die nötigen Suchpfade, um das angegebene Paket
erstellen zu können. Um eine „reine“ Umgebung zu erstellen, in der die
ursprünglichen Umgebungsvariablen nicht mehr vorkommen, kann die
Befehlszeilenoption --pure benutzt werden16.
Eine Guix-Umgebung zu verlassen ist gleichbedeutend mit dem Verlassen der
Shell; danach findet sich der Benutzer in der alten Umgebung wieder, in der
er sich vor dem Aufruf von guix environment
befand. Beim nächsten
Durchlauf des Müllsammlers (siehe guix gc
aufrufen) werden Pakete von
der Platte gelöscht, die innerhalb der Umgebung installiert worden sind und
außerhalb nicht länger benutzt werden.
guix environment
definiert die Variable GUIX_ENVIRONMENT
in
der neu erzeugten Shell. Ihr Wert ist der Dateiname des Profils dieser neuen
Umgebung. Das könnten Nutzer verwenden, um zum Beispiel eine besondere
Prompt als Eingabeaufforderung für Entwicklungsumgebungen in ihrer
.bashrc festzulegen (siehe Bash Startup Files in Referenzhandbuch von GNU Bash):
if [ -n "$GUIX_ENVIRONMENT" ] then export PS1="\u@\h \w [dev]\$ " fi
… oder um ihr Profil durchzusehen:
$ ls "$GUIX_ENVIRONMENT/bin"
Des Weiteren kann mehr als ein Paket angegeben werden. In diesem Fall wird die Vereinigung der Eingaben der jeweiligen Pakete zugänglich gemacht. Zum Beispiel erzeugt der folgende Befehl eine Shell, in der alle Abhängigkeiten von sowohl Guile als auch Emacs verfügbar sind:
guix environment guile emacs
Manchmal will man keine interaktive Shell-Sitzung. Ein beliebiger Befehl
kann aufgerufen werden, indem Sie nach Angabe der Pakete noch --
vor
den gewünschten Befehl schreiben, um ihn von den übrigen Argumenten
abzutrennen:
guix environment guile -- make -j4
In anderen Situationen ist es bequemer, aufzulisten, welche Pakete in der
Umgebung benötigt werden. Zum Beispiel führt der folgende Befehl
python
aus einer Umgebung heraus aus, in der Python 3 und
NumPy enthalten sind:
guix environment --ad-hoc python-numpy python -- python3
Man kann auch sowohl die Abhängigkeiten eines Pakets haben wollen als auch ein paar zusätzliche Pakete, die nicht Erstellungs- oder Laufzeitabhängigkeiten davon sind, aber trotzdem bei der Entwicklung nützlich sind. Deshalb hängt die Wirkung von der Position der Befehlszeilenoption --ad-hoc ab. Pakete, die links von --ad-hoc stehen, werden als Pakete interpretiert, deren Abhängigkeiten zur Umgebung hinzugefügt werden. Pakete, die rechts stehen, werden selbst zur Umgebung hinzugefügt. Zum Beispiel erzeugt der folgende Befehl eine Guix-Entwicklungsumgebung, die zusätzlich Git und strace umfasst:
guix environment --pure guix --ad-hoc git strace
Manchmal ist es wünschenswert, die Umgebung so viel wie möglich zu isolieren, um maximale Reinheit und Reproduzierbarkeit zu bekommen. Insbesondere ist es wünschenswert, den Zugriff auf /usr/bin und andere Systemressourcen aus der Entwicklungsumgebung heraus zu verhindern, wenn man Guix auf einer fremden Wirtsdistribution benutzt, die nicht Guix System ist. Zum Beispiel startet der folgende Befehl eine Guile-REPL in einer isolierten Umgebung, einem sogenannten „Container“, in der nur der Store und das aktuelle Arbeitsverzeichnis eingebunden sind:
guix environment --ad-hoc --container guile -- guile
Anmerkung: Die Befehlszeilenoption --container funktioniert nur mit Linux-libre 3.19 oder neuer.
Ein weiterer typischer Anwendungsfall für Container ist, gegenüber
Sicherheitslücken anfällige Anwendungen auszuführen, z.B. Webbrowser. Um
Eolie auszuführen, müssen wir den Zugriff auf manche Dateien und
Verzeichnisse über --expose und --share gewähren. Wir
lassen nss-certs
bereitstellen und machen /etc/ssl/certs/ für
die HTTPS-Authentifizierung sichtbar. Zu guter Letzt behalten wir die
DISPLAY
-Umgebungsvariable bei, weil isolierte grafische Anwendungen
ohne sie nicht angezeigt werden können.
guix environment --preserve='^DISPLAY$' --container --network \ --expose=/etc/machine-id \ --expose=/etc/ssl/certs/ \ --share=$HOME/.local/share/eolie/=$HOME/.local/share/eolie/ \ --ad-hoc eolie nss-certs dbus -- eolie
Im Folgenden werden die verfügbaren Befehlszeilenoptionen zusammengefasst.
--check
Hiermit wird die Umgebung angelegt und gemeldet, ob die Shell Umgebungsvariable überschreiben würde. Siehe --check für weitere Informationen.
--root=Datei
¶-r Datei
Die Datei zu einer symbolischen Verknüpfung auf das Profil dieser Umgebung machen und als eine Müllsammlerwurzel registrieren.
Das ist nützlich, um seine Umgebung vor dem Müllsammler zu schützen und sie „persistent“ zu machen.
Wird diese Option weggelassen, ist die Umgebung nur, solange die Sitzung von
guix environment
besteht, vor dem Müllsammler sicher. Das
bedeutet, wenn Sie das nächste Mal dieselbe Umgebung neu erzeugen, müssen
Sie vielleicht Pakete neu erstellen oder neu herunterladen. guix gc
aufrufen hat mehr Informationen über Müllsammlerwurzeln.
--expression=Ausdruck
-e Ausdruck
Eine Umgebung für das Paket oder die Liste von Paketen erzeugen, zu der der Ausdruck ausgewertet wird.
Zum Beispiel startet dies:
guix environment -e '(@ (gnu packages maths) petsc-openmpi)'
eine Shell mit der Umgebung für eben diese bestimmte Variante des Pakets PETSc.
Wenn man dies ausführt:
guix environment --ad-hoc -e '(@ (gnu) %base-packages)'
bekommt man eine Shell, in der alle Basis-Pakete verfügbar sind.
Die obigen Befehle benutzen nur die Standard-Ausgabe des jeweiligen Pakets. Um andere Ausgaben auszuwählen, können zweielementige Tupel spezifiziert werden:
guix environment --ad-hoc -e '(list (@ (gnu packages bash) bash) "include")'
--load=Datei
-l Datei
Eine Umgebung erstellen für das Paket oder die Liste von Paketen, zu der der Code in der Datei ausgewertet wird.
Zum Beispiel könnte die Datei eine Definition wie diese enthalten (siehe Pakete definieren):
(use-modules (guix) (gnu packages gdb) (gnu packages autotools) (gnu packages texinfo)) ;; Augment the package definition of GDB with the build tools ;; needed when developing GDB (and which are not needed when ;; simply installing it.) (package (inherit gdb) (native-inputs (modify-inputs (package-native-inputs gdb) (prepend autoconf-2.64 automake texinfo))))
--manifest=Datei
-m Datei
Eine Umgebung für die Pakete erzeugen, die im Manifest-Objekt enthalten sind, das vom Scheme-Code in der Datei geliefert wird. Wenn diese Befehlszeilenoption mehrmals wiederholt angegeben wird, werden die Manifeste aneinandergehängt.
Dies verhält sich ähnlich wie die gleichnamige Option des Befehls
guix package
(siehe --manifest)
und benutzt auch dieselben Manifestdateien.
Siehe guix shell --export-manifest
für Informationen, wie Sie Befehlszeilenoptionen in ein Manifest
„verwandeln“ können.
--ad-hoc
Alle angegebenen Pakete in der resultierenden Umgebung einschließen, als wären sie Eingaben eines ad hoc definierten Pakets. Diese Befehlszeilenoption ist nützlich, um schnell Umgebungen aufzusetzen, ohne dafür einen Paketausdruck schreiben zu müssen, der die gewünschten Eingaben enthält.
Zum Beispiel wird mit diesem Befehl:
guix environment --ad-hoc guile guile-sdl -- guile
guile
in einer Umgebung ausgeführt, in der sowohl Guile als auch
Guile-SDL zur Verfügung stehen.
Beachten Sie, dass in diesem Beispiel implizit die vorgegebene Ausgabe von
guile
und guile-sdl
verwendet wird, es aber auch möglich ist,
eine bestimmte Ausgabe auszuwählen – z.B. wird mit glib:bin
die Ausgabe bin
von glib
gewählt (siehe Pakete mit mehreren Ausgaben.).
Diese Befehlszeilenoption kann mit dem standardmäßigen Verhalten von
guix environment
verbunden werden. Pakete, die vor
--ad-hoc aufgeführt werden, werden als Pakete interpretiert, deren
Abhängigkeiten zur Umgebung hinzugefügt werden, was dem standardmäßigen
Verhalten entspricht. Pakete, die danach aufgeführt werden, werden selbst
zur Umgebung hinzugefügt.
--profile=Profil
-p Profil
Eine Umgebung mit den Paketen erzeugen, die im Profil installiert
sind. Benutzen Sie guix package
(siehe guix package
aufrufen), um Profile anzulegen und zu verwalten.
--pure
Bestehende Umgebungsvariable deaktivieren, wenn die neue Umgebung erzeugt wird, mit Ausnahme der mit --preserve angegebenen Variablen (siehe unten). Dies bewirkt, dass eine Umgebung erzeugt wird, in der die Suchpfade nur Paketeingaben nennen und sonst nichts.
--preserve=Regexp
-E Regexp
Wenn das hier zusammen mit --pure angegeben wird, bleiben die zum regulären Ausdruck Regexp passenden Umgebungsvariablen erhalten – mit anderen Worten werden sie auf eine „weiße Liste“ von Umgebungsvariablen gesetzt, die erhalten bleiben müssen. Diese Befehlszeilenoption kann mehrmals wiederholt werden.
guix environment --pure --preserve=^SLURM --ad-hoc openmpi … \ -- mpirun …
In diesem Beispiel wird mpirun
in einem Kontext ausgeführt, in dem
die einzig definierten Umgebungsvariablen PATH
und solche sind, deren
Name mit ‘SLURM’ beginnt, sowie die üblichen besonders „kostbaren“
Variablen (HOME
, USER
, etc.).
--search-paths
Die Umgebungsvariablendefinitionen anzeigen, aus denen die Umgebung besteht.
--system=System
-s System
Versuchen, für das angegebene System zu erstellen – z.B.
i686-linux
.
--container
¶-C
Den Befehl in einer isolierten Umgebung (einem sogenannten „Container“) ausführen. Das aktuelle Arbeitsverzeichnis außerhalb des Containers wird in den Container zugeordnet. Zusätzlich wird, wenn es mit der Befehlszeilenoption --user nicht anders spezifiziert wurde, ein stellvertretendes persönliches Verzeichnis erzeugt, dessen Inhalt der des wirklichen persönlichen Verzeichnisses ist, sowie eine passend konfigurierte Datei /etc/passwd.
Der erzeugte Prozess läuft außerhalb des Containers als der momentane Nutzer. Innerhalb des Containers hat er dieselbe UID und GID wie der momentane Nutzer, außer die Befehlszeilenoption --user wird übergeben (siehe unten).
--network
-N
Bei isolierten Umgebungen („Containern“) wird hiermit der Netzwerk-Namensraum mit dem des Wirtssystems geteilt. Container, die ohne diese Befehlszeilenoption erzeugt wurden, haben nur Zugriff auf das Loopback-Gerät.
--link-profile
-P
Bei isolierten Umgebungen („Containern“) wird das Umgebungsprofil im
Container als ~/.guix-profile verknüpft und ~/.guix-profile
dann in GUIX_ENVIRONMENT
gespeichert. Das ist äquivalent dazu,
~/.guix-profile im Container zu einer symbolischen Verknüpfung auf
das tatsächliche Profil zu machen. Wenn das Verzeichnis bereits existiert,
schlägt das Verknüpfen fehl und die Umgebung wird nicht hergestellt. Dieser
Fehler wird immer eintreten, wenn guix environment
im persönlichen
Verzeichnis des Benutzers aufgerufen wurde.
Bestimmte Pakete sind so eingerichtet, dass sie in ~/.guix-profile nach Konfigurationsdateien und Daten suchen,17 weshalb --link-profile benutzt werden kann, damit sich diese Programme auch in der isolierten Umgebung wie erwartet verhalten.
--user=Benutzer
-u Benutzer
Bei isolierten Umgebungen („Containern“) wird der Benutzername Benutzer anstelle des aktuellen Benutzers benutzt. Der erzeugte Eintrag in /etc/passwd im Container wird also den Namen Benutzer enthalten und das persönliche Verzeichnis wird den Namen /home/BENUTZER tragen; keine GECOS-Daten über den Nutzer werden in die Umgebung übernommen. Des Weiteren sind UID und GID innerhalb der isolierten Umgebung auf 1000 gesetzt. Benutzer muss auf dem System nicht existieren.
Zusätzlich werden alle geteilten oder exponierten Pfade (siehe jeweils --share und --expose), deren Ziel innerhalb des persönlichen Verzeichnisses des aktuellen Benutzers liegt, relativ zu /home/BENUTZER erscheinen, einschließlich der automatischen Zuordnung des aktuellen Arbeitsverzeichnisses.
# wird Pfade als /home/foo/wd, /home/foo/test und /home/foo/target exponieren cd $HOME/wd guix environment --container --user=foo \ --expose=$HOME/test \ --expose=/tmp/target=$HOME/target
Obwohl dies das Datenleck von Nutzerdaten durch Pfade im persönlichen Verzeichnis und die Benutzereinträge begrenzt, kann dies nur als Teil einer größeren Lösung für Datenschutz und Anonymität sinnvoll eingesetzt werden. Es sollte nicht für sich allein dazu eingesetzt werden.
--no-cwd
In isolierten Umgebungen („Containern“) ist das vorgegebene Verhalten, das aktuelle Arbeitsverzeichnis mit dem isolierten Container zu teilen und in der Umgebung sofort in dieses Verzeichnis zu wechseln. Wenn das nicht gewünscht wird, kann das Angeben von --no-cwd dafür sorgen, dass das Arbeitsverzeichnis nicht automatisch geteilt wird und stattdessen in das Persönliche Verzeichnis („Home“-Verzeichnis) gewechselt wird. Siehe auch --user.
--expose=Quelle[=Ziel]
--share=Quelle[=Ziel]
Bei isolierten Umgebungen („Containern“) wird das Dateisystem unter Quelle vom Wirtssystem als Nur-Lese-Dateisystem Ziel (bzw. für --share auch mit Schreibrechten) im Container zugänglich gemacht. Wenn kein Ziel angegeben wurde, wird die Quelle auch als Ziel-Einhängepunkt in der isolierten Umgebung benutzt.
Im folgenden Beispiel wird eine Guile-REPL in einer isolierten Umgebung gestartet, in der das persönliche Verzeichnis des Benutzers als Verzeichnis /austausch nur für Lesezugriffe zugänglich gemacht wurde:
guix environment --container --expose=$HOME=/austausch --ad-hoc guile -- guile
--emulate-fhs
-F
In Containern wird eine Konfiguration emuliert, die dem Filesystem Hierarchy Standard (FHS) folgt, siehe dessen offizielle Spezifikation. Obwohl Guix von der FHS-Spezifikation abweicht, kann das System in Ihrem Container mit dieser Befehlszeilenoption zu anderen GNU/Linux-Distributionen ähnlicher werden. Dadurch lassen sich dortige Entwicklungsumgebungen reproduzieren und Sie können Programme testen und benutzen, die das Befolgen der FHS-Spezifikation voraussetzen. Wenn die Option angegeben wird, enthält der Container eine Version von glibc, die die im Container befindliche /etc/ld.so.cache als Zwischenspeicher gemeinsamer Bibliotheken ausliest (anders als glibc im normalen Gebrauch von Guix), und die im FHS verlangten Verzeichnisse /bin, /etc, /lib und /usr werden aus dem Profil des Containers übernommen.
guix environment
unterstützt auch alle gemeinsamen
Erstellungsoptionen, die von guix build
unterstützt werden (siehe
Gemeinsame Erstellungsoptionen), und die Paketumwandlungsoptionen (siehe
Paketumwandlungsoptionen).
Manchmal
ergänzen Nutzer fälschlicherweise Umgebungsvariable wie PATH
in ihrer
~/.bashrc-Datei. Das hat zur Folge, dass wenn guix
environment
Bash startet, selbige ~/.bashrc von Bash gelesen wird
und die neuen Umgebungen somit „verunreinigt“. Es ist ein Fehler, solche
Umgebungsvariable in .bashrc zu definieren, stattdessen sollten sie
in .bash_profile geschrieben werden, was nur von Login-Shells mit
„source“ geladen wird. Siehe Bash Startup Files in Referenzhandbuch zu GNU Bash für Details über beim Starten von Bash
gelesene Dateien
Zum Beispiel
inspiziert das Paket fontconfig
das Verzeichnis
~/.guix-profile/share/fonts, um zusätzliche Schriftarten zu finden.
Nächste: guix pack
aufrufen, Vorige: guix shell
aufrufen, Nach oben: Entwicklung [Inhalt][Index]