Eine Conda-Umgebung sauber zu exportieren spart später viel Zeit, vor allem wenn Projekte zwischen Laptop, Server und CI-Runner wandern. Die eigentliche Aufgabe hinter conda export environment ist simpel: eine Umgebung so festzuhalten, dass sie sich später reproduzierbar wiederherstellen lässt. Ich zeige dir den aktuellen Standard mit conda export, die weiter unterstützte Variante conda env export und die Optionen, mit denen die Datei wirklich brauchbar bleibt.
Die wichtigsten Punkte in Kürze
-
Der moderne Weg ist heute
conda export;conda env exportbleibt für YAML-Dateien weiterhin unterstützt. -
Für Teamarbeit ist
environment-yamlmeist die beste Wahl, weil die Datei lesbar und gut versionierbar ist. -
Für exakte Reproduktion auf derselben Plattform ist
explicitdeutlich strenger als eine normale YAML-Spezifikation. -
--from-historymacht Exporte portabler, weil nur explizit installierte Pakete landen. -
--no-buildsreduziert unnötige Strenge, kann aber die Genauigkeit des Exports verringern. -
Zur Wiederherstellung nutzt man meist
conda env create -f environment.ymloder, bei bestehenden Umgebungen,conda env update -f environment.yml --prune.
Warum der Export einer Conda-Umgebung mehr ist als eine Sicherheitskopie
Ich behandle den Export nie als bloßes Ablageformat, sondern als vertragliche Beschreibung einer Entwicklungsumgebung. Darin stecken typischerweise Paketnamen, Versionen, Channels und je nach Format auch Build- oder Plattformdetails. Genau das macht den Unterschied zwischen einer Umgebung, die man nach einer Woche noch versteht, und einer, die nur auf dem ursprünglichen Rechner zufällig funktioniert.
Wichtig ist auch die Grenze: Ein Export ist kein Vollbackup des gesamten Systems. Lokale Daten, Editor-Einstellungen, Datenbanken oder Dateien außerhalb von Conda landen nicht automatisch in der Konfigurationsdatei. Deshalb nutze ich den Export immer zusammen mit sauberer Projektstruktur und nicht als Ersatz für ein ordentliches Repository. Wenn man diese Trennung sauber hält, wird die nächste Frage ganz logisch: Welcher Befehl ist heute der richtige?
So exportiere ich eine Umgebung heute
Für neue Projekte würde ich zuerst conda export nehmen. Der Befehl ist moderner, unterstützt mehrere Formate und kann den Export über den Dateinamen oder die Dateiendung erkennen. conda env export ist weiterhin verfügbar und für klassische YAML-Dateien völlig in Ordnung, aber es ist eben die ältere, eingeschränktere Variante.
# aktive Umgebung exportieren
conda export --file=environment.yaml
# benannte Umgebung exportieren
conda export --name myenv --format=environment-yaml --file=environment.yaml
# Export über den Pfad zur Umgebung
conda export --prefix /pfad/zur/umgebung --file=environment.yaml
# klassische YAML-Variante
conda env export --name myenv > environment.ymlDer praktische Vorteil von conda export ist die Flexibilität: Ich kann das Zielformat bewusst setzen oder über den Dateinamen steuern. Gleichzeitig bleibt die Ausgabe lesbar und für viele Teams sofort verständlich. Sobald der Befehl klar ist, stellt sich die wichtigere Frage nach dem richtigen Format.
Welches Format ich für welchen Zweck nehme
Die Wahl des Formats entscheidet direkt darüber, ob du eine austauschbare Beschreibung oder ein möglichst exaktes Abbild erzeugst. In der Praxis sind vier Formate relevant, und jedes hat einen klaren Einsatzzweck. Ich würde sie nicht gegeneinander ausspielen, sondern bewusst nach Ziel auswählen.
| Format | Wofür geeignet | Stärke | Grenze |
|---|---|---|---|
environment-yaml |
Teams, Git-Repositories, Austausch zwischen Rechnern | Lesbar, gut versionierbar, Standard für viele Projekte | Nicht automatisch bitgenau, wenn Plattformen stark variieren |
environment-json |
Automatisierung, Tools, maschinelle Verarbeitung | Strukturiert und gut für Skripte | Für Menschen weniger angenehm als YAML |
explicit |
Exakte Wiederherstellung auf derselben Plattform | Sehr präzise, mit vollständigen Paket-URLs | Plattformgebunden und deutlich unflexibler |
requirements |
Schlanke, conda-kompatible Textdateien | Kompakt und einfach | Weniger ausdrucksstark als YAML oder JSON |
Wenn ich nur eine Datei im Team teilen will, nehme ich fast immer YAML. Wenn ich eine Umgebung aber auf einem bestimmten Rechner später exakt nachbauen muss, ist ein Lockfile im explicit-Stil die härtere, aber oft passendere Wahl. Genau an dieser Stelle entscheidet sich, ob dein Export später nur lesbar ist oder wirklich reproduzierbar.
Welche Optionen die Datei robuster machen
Hier trennt sich der saubere Export von der bloßen Paketliste. Drei Optionen nutze ich besonders oft, weil sie die Datei entweder portabler oder gezielter machen: --from-history, --no-builds und eine bewusste Behandlung von Channels und Plattformen.
Mit --from-history wird die Datei portabler
--from-history exportiert nur die Pakete, die du ausdrücklich installiert hast. Das ist nützlich, weil damit nicht jede transitive Abhängigkeit in der Datei landet, die auf deinem Rechner zufällig mit aufgelöst wurde. Ich verwende diese Option vor allem dann, wenn ein Projekt auf verschiedenen Systemen laufen soll oder wenn ich ein sauberes, eher absichtsorientiertes Environment-File will.
Der Haken ist wichtig: Diese Option funktioniert nur mit den strukturierten Formaten environment-yaml und environment-json. Für explicit oder requirements ist sie nicht gedacht. Wer diese Grenze ignoriert, bekommt schnell eine Datei, die zwar formal existiert, aber nicht das gewünschte Verhalten liefert.
--no-builds macht weniger streng, aber oft robuster
Build-Informationen sind in Conda manchmal hilfreich, können aber auch unnötig eng werden. Mit --no-builds entferne ich die Build-Spezifikation aus den Abhängigkeiten. Das ist praktisch, wenn zwei Maschinen denselben Paketstand brauchen, aber nicht exakt denselben Build-String.
Ich setze das allerdings nicht reflexhaft ein. Für eine exakte Reproduktion ist jeder entfernte Detailgrad ein Verlust an Präzision. Für Austausch und Wartung reicht die reduzierte Variante aber oft vollkommen aus.
Lesen Sie auch: FHIR - Interoperabilität im Gesundheitswesen verstehen
Channels und Plattformen bewusst festlegen
Wenn ein Projekt auf conda-forge basiert, schreibe ich das in die Datei oder halte es zumindest dokumentiert fest. Sonst kann die spätere Auflösung anders ausfallen, selbst wenn die Paketnamen gleich bleiben. Mit der bewussten Kontrolle von Channels vermeidest du genau die Art von stillen Abweichungen, die später schwer zu debuggen sind.
Plattformen sind die zweite Stellschraube. Ein Export für linux-64 verhält sich nicht automatisch gleich wie einer für osx-arm64 oder win-64. Für wirklich robuste Setups plane ich deshalb früh, ob ich eine portable Spezifikation oder ein plattformspezifisches Lockfile brauche. Wer diese Unterscheidung überspringt, wundert sich oft erst beim ersten Deployment.
Typische Fehler, die ich in Projekten immer wieder sehe
Die meisten Probleme entstehen nicht beim Befehl selbst, sondern beim Zustand der Umgebung. Ein Export ist nur so gut wie die Basis, aus der er erzeugt wurde. Deshalb prüfe ich vor dem Export immer, ob die Umgebung sauber, nachvollziehbar und nicht mit Experimenten überladen ist.
- Zu früh exportiert - Wer vor dem Aufräumen exportiert, konserviert halbfertige Tests und unnötige Pakete gleich mit.
- Falsches Format gewählt - Eine YAML-Datei ist gut für Austausch, aber kein Ersatz für ein präzises Lockfile.
- Channels vergessen - Ohne dokumentierte Quellen kann sich die Paketauflösung später sichtbar ändern.
- Builds zu streng oder zu locker behandelt - Mit Build-Strings wird der Export exakter, ohne sie oft robuster, aber weniger genau.
- Pip-Schritte nicht separat dokumentiert - Wenn neben Conda noch weitere Installationsschritte nötig sind, halte ich sie zusätzlich fest, statt sie implizit zu lassen.
Ein weiterer Punkt, der gern übersehen wird: Exportdateien können ohne Rückfrage überschrieben werden. Ich arbeite deshalb bewusst mit klaren Dateinamen und speichere Exporte direkt im Projekt, nicht irgendwo auf Zuruf. Wenn der Export sitzt, muss er sich im nächsten Schritt auch sauber wieder einlesen lassen.
So importiere ich die Datei wieder sauber
Für eine neue Umgebung reicht meist conda env create -f environment.yml. Conda erkennt Standardformate am Dateinamen oder am Inhalt, was im Alltag überraschend viel Reibung spart. Wenn ich bestehende Umgebungen anpassen will, nutze ich conda env update -f environment.yml --prune, damit nicht mehr benötigte Pakete entfernt werden.
# neue Umgebung erstellen
conda env create -f environment.yml
# bestehende Umgebung aktualisieren
conda env update -f environment.yml --pruneBei Sondernamen würde ich das Format explizit angeben, damit keine Missverständnisse entstehen. Das ist besonders dann sinnvoll, wenn die Datei nicht environment.yml heißt oder wenn mehrere Formate im gleichen Projekt vorkommen. Für einfache Team-Setups ist genau diese Klarheit meist mehr wert als ein zusätzlicher Befehl.
Welche Exportstrategie ich für Teamprojekte bevorzuge
Für die meisten Projekte setze ich auf eine zweistufige Logik: ein lesbares YAML für den Alltag und ein strengeres Lockfile für reproduzierbare Releases. Das YAML hält die Absicht fest, das Lockfile die konkrete Ausführung. Genau diese Trennung verhindert, dass ein Projekt über Monate stillschweigend auseinanderläuft.
Wenn ich nur eine Routine empfehlen dürfte, dann diese: Nach jeder relevanten Änderung an Python-Version, Channel oder Kernpaketen sofort neu exportieren und die Datei mit ins Repository nehmen. So bleibt der Zustand nicht im Kopf einzelner Personen hängen, sondern im Projekt selbst. Und genau das ist der Punkt, an dem ein Conda-Export seinen eigentlichen Wert zeigt: nicht als bloße Datei, sondern als verlässliche Arbeitsgrundlage.
