Nächste: , Vorige: , Nach oben: Entwicklung   [Inhalt][Index]


8.2 guix environment aufrufen

Der 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 Sie guix shell benutzen, was einen ähnlichen Zweck erfüllt, aber leichter zu benutzen ist. Siehe guix shell aufrufen.

Veraltet heißt, guix environment wird letztendlich entfernt, aber das Guix-Projekt wird gewährleisten, dass guix 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).


Fußnoten

(16)

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

(17)

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]