Nächste: Die Store-Monade, Vorige: Der Store, Nach oben: Programmierschnittstelle [Inhalt][Index]
Systemnahe Erstellungsaktionen sowie die Umgebung, in der selbige durchzuführen sind, werden durch Ableitungen dargestellt. Eine Ableitung enthält folgende Informationen:
x86_64-linux
.
Ableitungen ermöglichen es den Clients des Daemons, diesem
Erstellungsaktionen für den Store mitzuteilen. Es gibt davon zwei Arten,
sowohl Darstellungen im Arbeitsspeicher jeweils für Client und Daemon als
auch Dateien im Store, deren Namen auf .drv enden – diese
Dateien werden als Ableitungspfade bezeichnet. Ableitungspfade können
an die Prozedur build-derivations
übergeben werden, damit die darin
niedergeschriebenen Erstellungsaktionen durchgeführt werden (siehe Der Store).
Operationen wie das Herunterladen von Dateien und Checkouts von unter Versionskontrolle stehenden Quelldateien, bei denen der Hash des Inhalts im Voraus bekannt ist, werden als Ableitungen mit fester Ausgabe modelliert. Anders als reguläre Ableitungen sind die Ausgaben von Ableitungen mit fester Ausgabe unabhängig von ihren Eingaben – z.B. liefert das Herunterladen desselben Quellcodes dasselbe Ergebnis unabhängig davon, mit welcher Methode und welchen Werkzeugen er heruntergeladen wurde.
Den Ausgaben von Ableitungen – d.h. Erstellungergebnissen – ist
eine Liste von Referenzen zugeordnet, die auch der entfernte
Prozeduraufruf references
oder der Befehl guix gc
--references
liefert (siehe guix gc
aufrufen). Referenzen sind die
Menge der Laufzeitabhängigkeiten von Erstellungsergebnissen. Referenzen sind
eine Teilmenge der Eingaben von Ableitungen; die Teilmenge wird automatisch
ermittelt, indem der Erstellungsdaemon alle Dateien unter den Ausgaben nach
Referenzen durchsucht.
Das Modul (guix derivations)
stellt eine Repräsentation von
Ableitungen als Scheme-Objekte zur Verfügung, zusammen mit Prozeduren, um
Ableitungen zu erzeugen und zu manipulieren. Die am wenigsten abstrahierte
Methode, eine Ableitung zu erzeugen, ist mit der Prozedur derivation
:
(%current-system)] [#:references-graphs #f] [#:allowed-references #f]
[#:disallowed-references #f] [#:leaked-env-vars #f] [#:local-build? #f] [#:substitutable? #t] [#:properties ’()] Eine Ableitungen mit den
Argumenten erstellen und das resultierende <derivation>
-Objekt
liefern.
Wurden hash und hash-algo angegeben, wird eine Ableitung mit fester Ausgabe erzeugt – d.h. eine, deren Ausgabe schon im Voraus bekannt ist, wie z.B. beim Herunterladen einer Datei. Wenn des Weiteren auch recursive? wahr ist, darf die Ableitung mit fester Ausgabe eine ausführbare Datei oder ein Verzeichnis sein und hash muss die Prüfsumme eines Archivs mit dieser Ausgabe sein.
Ist references-graphs wahr, dann muss es eine Liste von Paaren aus je einem Dateinamen und einem Store-Pfad sein. In diesem Fall wird der Referenzengraph jedes Store-Pfads in einer Datei mit dem angegebenen Namen in der Erstellungsumgebung zugänglich gemacht, in einem einfachen Text-Format.
Ist allowed-references ein wahr, muss es eine Liste von Store-Objekten oder Ausgaben sein, die die Ausgabe der Ableitung referenzieren darf. Ebenso muss disallowed-references, wenn es auf wahr gesetzt ist, eine Liste von Dingen bezeichnen, die die Ausgaben nicht referenzieren dürfen.
Ist leaked-env-vars wahr, muss es eine Liste von Zeichenketten sein,
die Umgebungsvariable benennen, die aus der Umgebung des Daemons in die
Erstellungsumgebung überlaufen – ein „Leck“, englisch „leak“. Dies kann
nur in Ableitungen mit fester Ausgabe benutzt werden, also wenn hash
wahr ist. So ein Leck kann zum Beispiel benutzt werden, um Variable wie
http_proxy
an Ableitungen zu übergeben, die darüber Dateien
herunterladen.
Ist local-build? wahr, wird die Ableitung als schlechter Kandidat für das Auslagern deklariert, der besser lokal erstellt werden sollte (siehe Nutzung der Auslagerungsfunktionalität). Dies betrifft kleine Ableitungen, wo das Übertragen der Daten aufwendiger als ihre Erstellung ist.
Ist substitutable? falsch, wird deklariert, dass für die Ausgabe der Ableitung keine Substitute benutzt werden sollen (siehe Substitute). Das ist nützlich, wenn Pakete erstellt werden, die Details über den Prozessorbefehlssatz des Wirtssystems auslesen.
properties muss eine assoziative Liste enthalten, die „Eigenschaften“ der Ableitungen beschreibt. Sie wird genau so, wie sie ist, in der Ableitung gespeichert.
Hier ist ein Beispiel mit einem Shell-Skript, das als Ersteller benutzt wird. Es wird angenommen, dass Store eine offene Verbindung zum Daemon ist und bash auf eine ausführbare Bash im Store verweist:
(use-modules (guix utils) (guix store) (guix derivations)) (let ((builder ; das Ersteller-Bash-Skript in den Store einfügen (add-text-to-store store "my-builder.sh" "echo Hallo Welt > $out\n" '()))) (derivation store "foo" bash `("-e" ,builder) #:inputs `((,bash) (,builder)) #:env-vars '(("HOME" . "/homeless")))) ⇒ #<derivation /gnu/store/…-foo.drv => /gnu/store/…-foo>
Wie man sehen kann, ist es umständlich, diese grundlegende Methode direkt zu
benutzen. Natürlich ist es besser, Erstellungsskripts in Scheme zu
schreiben! Am besten schreibt man den Erstellungscode als „G-Ausdruck“ und
übergibt ihn an gexp->derivation
. Mehr Informationen finden Sie im
Abschnitt G-Ausdrücke.
Doch es gab einmal eine Zeit, zu der gexp->derivation
noch nicht
existiert hatte und wo das Zusammenstellen von Ableitungen mit
Scheme-Erstellungscode noch mit build-expression->derivation
bewerkstelligt wurde, was im Folgenden beschrieben wird. Diese Prozedur gilt
als veraltet und man sollte nunmehr die viel schönere Prozedur
gexp->derivation
benutzen.
[#:env-vars ’()] [#:modules ’()] [#:references-graphs #f]
[#:allowed-references #f] [#:disallowed-references #f] [#:local-build?
#f] [#:substitutable? #t] [#:guile-for-build #f] Liefert eine Ableitung, die
den Scheme-Ausdruck Ausdruck als Ersteller einer Ableitung namens
Name ausführt. inputs muss die Liste der Eingaben enthalten,
jeweils als Tupel (Name Ableitungspfad Unterableitung)
; wird keine
Unterableitung angegeben, wird "out"
angenommen. Module
ist eine Liste der Namen von Guile-Modulen im momentanen Suchpfad, die in
den Store kopiert, kompiliert und zur Verfügung gestellt werden, wenn der
Ausdruck ausgeführt wird – z.B. ((guix build utils) (guix
build gnu-build-system))
.
Der Ausdruck wird in einer Umgebung ausgewertet, in der
%outputs
an eine Liste von Ausgabe-/Pfad-Paaren gebunden wurde und in
der %build-inputs
an eine Liste von Zeichenkette-/Ausgabepfad-Paaren
gebunden wurde, die aus den inputs-Eingaben konstruiert worden
ist. Optional kann in env-vars eine Liste von Paaren aus Zeichenketten
stehen, die Name und Wert von für den Ersteller sichtbaren
Umgebungsvariablen angeben. Der Ersteller terminiert, indem er exit
mit dem Ergebnis des Ausdrucks aufruft; wenn also der Ausdruck
den Wert #f
liefert, wird angenommen, dass die Erstellung
fehlgeschlagen ist.
Ausdruck wird mit einer Ableitung guile-for-build erstellt. Wird
kein guile-for-build angegeben oder steht es auf #f
, wird
stattdessen der Wert der Fluiden %guile-for-build
benutzt.
Siehe die Erklärungen zur Prozedur derivation
für die Bedeutung von
references-graphs, allowed-references,
disallowed-references, local-build? und substitutable?.
Hier ist ein Beispiel einer Ableitung mit nur einer Ausgabe, die ein Verzeichnis erzeugt, in dem eine einzelne Datei enthalten ist:
(let ((builder '(let ((out (assoc-ref %outputs "out"))) (mkdir out) ; das Verzeichnis ; /gnu/store/…-goo erstellen (call-with-output-file (string-append out "/test") (lambda (p) (display '(Hallo Guix) p)))))) (build-expression->derivation store "goo" builder)) ⇒ #<derivation /gnu/store/…-goo.drv => …>
Nächste: Die Store-Monade, Vorige: Der Store, Nach oben: Programmierschnittstelle [Inhalt][Index]