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


5.1 guix environment aufrufen

Der Zweck von guix environment ist es, Hacker beim Aufbau einer reproduzierbaren Entwicklungsumgebung zu unterstützen, ohne dass diese ihr Paketprofil verunreinigen müssen. Das Werkzeug guix environment nimmt eines oder mehrere Pakete entgegen und erstellt erst all ihre Eingaben, um dann eine Shell-Umgebung herzustellen, in der diese benutzt werden können.

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 werden10.

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 The GNU Bash Reference Manual):

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 man nach Angabe der Pakete noch -- vor den gewünschten Befehl schreibt, 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 2.7 und NumPy enthalten sind:

guix environment --ad-hoc python2-numpy python-2.7 -- python

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.

Im Folgenden werden die verfügbaren Befehlszeilenoptionen zusammengefasst.

--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. Aufruf von guix gc 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 `(("autoconf" ,autoconf-2.64)
                   ("automake" ,automake)
                   ("texinfo" ,texinfo)
                   ,@(package-native-inputs gdb))))
--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.

--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.

--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. Das ist äquivalent dazu, den Befehl ln -s $GUIX_ENVIRONMENT ~/.guix-profile im Container auszuführen. 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,11 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

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

(10)

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 The GNU Bash Reference Manual für Details über beim Starten von Bash gelesene Dateien

(11)

Zum Beispiel inspiziert das Paket fontconfig das Verzeichnis ~/.guix-profile/share/fonts, um zusätzliche Schriftarten zu finden.


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