Flox 1.0 – Open-Source-Entwicklungsumgebungen mit Nix als Code definieren

 (github.com/flox)
3 Punkte von GN⁺ 2024-03-14 | 1 Kommentare | Auf WhatsApp teilen
  • Flox ist eine Plattform für Softwareumgebungen für Engineering-Teams, die mit einem einzigen Manifest identische, reproduzierbare Umgebungen vom Entwickler-Laptop über CI bis zur Produktion verwaltet
  • Die Grundlage ist Nix, aber Nix-Kenntnisse sind optional; durch deklarative Manifeste und kryptografisch fixierte Inhalte per Content-Hash-Eingaben wird Umgebungsdrift reduziert
  • Es läuft auf macOS, Linux und Windows WSL2, kann in Nixpkgs nach mehr als 120.000 Paketen suchen und diese installieren sowie eigene Software als reproduzierbare Pakete bauen und veröffentlichen
  • Mit dem Ablauf flox init, flox install, flox activate lassen sich isolierte Umgebungen pro Projekt erstellen; beim Aktivieren erscheinen die Tools, beim Verlassen verschwinden sie wieder und halten das System sauber
  • Der Fokus liegt auf dem Management des Lebenszyklus von Umgebungen auf Organisationsebene, einschließlich Freigabe über FloxHub, Erzeugung von OCI-Images, Ausführen von Services, SBOM, CVE-Patches, SCA und deterministischen Laufzeitumgebungen für AI-Coding-Agenten

Welches Problem Flox lösen will

  • Flox ist eine Plattform, die Entwicklungsumgebungen in einer Datei definiert und dafür sorgt, dass auf Entwickler-Laptops, in CI und in Produktion dieselbe Umgebung läuft
  • Während traditionelle Paketmanager auf die Installation von Paketen auf einer einzelnen Maschine fokussiert sind, verwaltet Flox den Lebenszyklus von Paketen und Umgebungen für die gesamte Organisation
  • Es gibt drei zentrale Eigenschaften
    • Deklarativ: Die für ein Projekt benötigten Tools, Umgebungsvariablen und Services werden in einer Datei beschrieben
    • Reproduzierbar: Dieselbe Definition erzeugt auf jedem unterstützten System dieselbe Umgebung
    • Kombinierbar: Umgebungen für Projekte, Teams und Pipelines können geschichtet werden

Zielgruppen und Einsatzumgebungen

  • Platform- und DevX-Teams können Toolchains organisationsweit standardisieren und Referenzumgebungen erweitern, ohne das Erlernen von Nix vorzuschreiben
  • Security- und AppSec-Teams können SBOMs, schnelle CVE-Reaktionen, die Herkunft von Abhängigkeiten und reproduzierbare Builds behandeln
  • Entwickler können auf macOS, Linux und Windows WSL2 reproduzierbare Umgebungen pro Projekt nutzen, die eher virtuellen Umgebungen als Containern oder VMs ähneln
  • AI-Coding-Agenten erhalten deterministische Umgebungen, in denen generierter Code jedes Mal auf dieselbe Weise gebaut und ausgeführt werden kann
    • Genannte Beispiele sind Claude Code, Cursor, Copilot und Codex

Reproduzierbarkeit und Sicherheit der Lieferkette

  • Flox-Umgebungen werden mit einem deklarativen Manifest definiert und an kryptografisch fixierte Content-Hash-Eingaben gebunden
  • Dieselbe Lockfile wird auf jedem unterstützten System zu denselben Paketen aufgelöst, sodass Umgebungen über Maschinen hinweg identisch bleiben
  • Eine einzige Umgebungsdefinition kann auf Entwickler-Laptops, in Sandboxen für AI-Agenten, in CI und in Produktion verwendet werden
  • Es stehen mehr als 120.000 Pakete aus Nixpkgs zur Verfügung
  • Eigene Software kann aus dem Quellcode gebaut, in reproduzierbare Pakete verwandelt und zur Nutzung im gesamten Team veröffentlicht werden
  • Auf Basis dieser Reproduzierbarkeit werden SBOM-Erstellung, Software Composition Analysis (SCA), automatisierte Patches für Schwachstellen und CVEs, die Prüfung der Herkunft von Abhängigkeiten und auditierbare Builds einfacher

Installation und grundlegender Workflow

  • Die Flox CLI wird nativ auf macOS, Linux und Windows WSL2 installiert
    • macOS: brew install flox oder das Installationspaket .pkg
    • Linux: .deb für Debian/Ubuntu, .rpm für Fedora/RHEL
    • Windows: Nutzung der Linux-Pakete unter WSL2
  • Der grundlegende Ablauf besteht darin, innerhalb eines Projekts eine Umgebung zu erstellen, die benötigten Pakete zu installieren und die Umgebung anschließend zu aktivieren
    • flox init: Umgebung im Projekt erstellen
    • flox install python3 nodejs: Pakete in der Umgebung installieren
    • flox activate: Umgebung betreten
  • Im README-Beispiel liefert python3 --version innerhalb der aktivierten Umgebung Python 3.13.13, und node --version ergibt v24.15.0
  • Beim Verlassen der Umgebung verschwinden die installierten Tools wieder, wodurch Konflikte zwischen Projekten vermieden und das System sauber gehalten wird

Hauptfunktionen

  • Create: Mit flox init kann eine deklarative Umgebung neben dem Code erstellt und automatisch aktiviert werden
  • Search: Mit flox search lassen sich mehr als 120.000 Pakete aus Nixpkgs finden
  • Share: Mit flox push / flox pull können Teammitglieder dieselbe Referenzumgebung aus FloxHub übernehmen
  • Containerize: Mit flox containerize lässt sich eine Flox-Umgebung ohne Dockerfile in ein OCI-Image umwandeln
  • Build & publish: Mit flox build / flox publish kann eigene Software als reproduzierbares Paket gebaut und im Team veröffentlicht werden
  • Services: Mit flox services start können Datenbanken, Queues und Hintergrundprozesse als Teil der Umgebung ausgeführt werden; sie starten bei der Aktivierung und stoppen beim Beenden
  • Configure: In manifest.toml werden Umgebungsvariablen, Shell-Hooks und Aktivierungsskripte deklarativ definiert
  • AI-ready: Über flox-agentic wird unterstützt, dass AI-Coding-Agenten bei jedem Lauf mit denselben Abhängigkeiten bauen und ausführen

Einordnung für Docker- und Nix-Nutzer

  • Flox ist keine Containertechnologie und kein Ersatz für Docker
  • In Docker werden Packaging und Container-Isolation oft vermischt, während Flox den Standpunkt vertritt, dass Software-Packaging und die gewählte Form der Isolation getrennt werden sollten
  • Flox-Umgebungen funktionieren auf Bare Metal, in VMs und in Containern auf dieselbe Weise
  • flox containerize erstellt OCI-Images mit enthaltener Softwareumgebung und kann zusammen mit Docker, Kubernetes und anderen Container-Runtimes genutzt werden
  • Für Nix-Nutzer ist Flox kein Ersatz, sondern ein zusätzliches Werkzeug
    • Es bietet mit FloxHub einen zentralen Service für kollaborative Umgebungen und das Teilen von Paketen
    • Aktivierungshooks, Services und Shell-Profile werden in einer einzigen deklarativen TOML-Datei gebündelt

Herkunft und unterstützende Ressourcen

  • Flox entstand aus groß angelegten Enterprise-Nix-Deployments der D.E. Shaw group und wurde genutzt, um Nix in großen Engineering-Organisationen zugänglicher zu machen
  • Relevante Ressourcen
  • Sicherheitsrelevante Anfragen werden unter security@flox.dev entgegengenommen
  • Die Lizenz der Flox CLI ist GPLv2

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-03-14
Hacker-News-Kommentare

  • Ron, Glückwunsch zum Launch. Mich interessiert, wie das Erlösmodell aussieht.
    Es gibt einen CEO, ein Unternehmen und Mitarbeitende, und laut Crunchbase sieht es so aus, als hättet ihr 24 Mio. US-Dollar Finanzierung erhalten, aber auf der Landingpage oder in der Dokumentation finde ich keine Preisinformationen.
    Auch wenn ich mich mit meinem GitHub-Profil bei FloxHub anmelde, sehe ich keine Zahlungsoptionen; mich würde interessieren, was geplant ist.

    • Danke für den Hinweis. Die heute veröffentlichte kostenlose und Open-Source-Form war einer der Hauptgründe, warum wir Flox gestartet haben, und wir planen, künftig noch mehr hineinzupacken.
      Der heute veröffentlichte Open-Source-Client und der FloxHub-Service zum Teilen von Environments werden dauerhaft kostenlos angeboten.
      Später wollen wir einen leistungsfähigeren privaten Software-Katalog anbieten, der auf dem grundlegenden Flox Catalog aufsetzt.
      Wenn ihr eigene Artefakte verteilen oder angepasste Versionen von Open-Source-Paketen innerhalb von Flox benötigt, wollen wir es euch leicht machen, einen eigenen Katalog zu erstellen, der den dauerhaft kostenlosen Flox Catalog ergänzt.
      Langfristig möchten wir Enterprise-Lösungen in Form von Abonnements und Services verkaufen, damit Unternehmen ihre umfangreichen und fragmentierten Software-Lieferketten besser verwalten können; wir halten es für sinnvoll, dass Unternehmen die Kosten für die Entwicklung unternehmensspezifischer Tools mittragen.
    • Dass ihr 24 Mio. US-Dollar bekommen habt, überrascht mich. Ich sehe nicht wirklich den Weg von hier zu einem 2,4-Mrd.-US-Dollar-Exit, aber viel Glück.

  • Jedes Mal, wenn ich im README Formulierungen wie „Nix macht es neuen Nutzern leichter“ oder Ähnliches sehe, bleibe ich daran hängen.
    Ich halte mich für ziemlich kompetent, aber bei der Nutzung von Nix habe ich noch nie gedacht: „Das war einfach.“
    Die Konzepte von Nix finde ich wirklich großartig, aber die User Experience ist furchtbar. Vielleicht löst dieses Tool genau das, aber um überhaupt dorthin zu kommen, muss man sich mangels Dokumentation durch bereits verworfene Ansätze kämpfen und endlos an der Konfiguration herumdrehen, was sehr frustrierend ist.
    Jedenfalls denke ich jedes Mal, wenn ich etwas zu Nix sehe: „Ich freue mich auf den Tag, an dem das einfacher wird.“

    • Falls du den Satz „Flox entstand während der Einführung von Nix bei der D. E. Shaw Group, und sein Wert zeigte sich schnell, weil es Nix für neue Nutzer einfacher machte“ meinst: Das klingt für mich genau andersherum als deine ursprüngliche Interpretation.
    • Der Satz bedeutet nicht, dass Nix für neue Nutzer einfach ist, sondern liest sich so, dass Flox Nix einfacher macht.
    • Exakt dieselbe Erfahrung. Ich habe mich ziemlich lange mit NixOS beschäftigt, bin aber mit .nix oder Flakes nie wirklich warm geworden.
      Die Grundkonzepte sind mir ständig wieder aus dem Kopf gefallen, sodass ich jedes Mal, wenn ich etwas Neues einrichten wollte, wieder nachschlagen musste – am Ende habe ich aufgegeben.
      Auch das Debuggen von Problemen ist schwierig; um herauszufinden, was falsch läuft, muss man sehr spezifische Befehle kennen und sich durch ein höllisches Dateisystem wühlen.
      Die Konzepte gefallen mir, aber in der Praxis fühlt es sich so an, als stünde es einem viel zu oft im Weg.
    • Ich mag Nix und habe auch etliche Pakete zum nix-Repository beigetragen, aber einfach würde ich es auf keinen Fall nennen.
      Mit meinem Haskell-Hintergrund fühlt es sich zwar vertrauter an, aber schon die Syntax selbst ist für neue Nutzer nicht intuitiv.
    • Stimme stark zu. Man sieht die Vorteile, aber die anfängliche Lernkurve ist extrem steil.
      Es erinnert mich an das Lernen von Rust, was irgendwie auch Spaß macht.

  • Das Kernproblem bei Produkten nach dem Muster „die Power von Nix ohne Lernkurve“ ist, dass im Hintergrund weiterhin Nix und /nix/store stehen, und Nix bereinigt das absichtlich nicht automatisch.
    Wenn Nutzer ein Tool verwenden, das Nix versteckt, ist irgendwann die Festplatte voll; da sie nicht wissen, wie sie Speicherplatz freigeben können, ist das schwerlich nutzerfreundlich.
    Anders ist es, wenn Nutzer wissen, dass sie Nix installieren, und den Lernprozess durchlaufen: Dann können sie ein mentales Modell davon aufbauen, was /nix/store ist und wie man ihn verwaltet.
    Mich interessiert, wie ihr mit dieser Komplexität im Unterbau umgehen wollt.

    • Wenn man Rollbacks und Historie unterstützt, wird die Festplatte zwangsläufig voll. In Nix zeigen normalerweise mehrere GC-Roots auf Profile und Pakete, sodass sie nicht bereinigt werden können.
      Flox-Environments sind keine einfachen Symlinks, sondern haben ein deklaratives Format – intern Flakes –, sodass man sie entfernen und bei Bedarf wieder reproduzieren kann.
      Dadurch ist Garbage Collection weniger destruktiv als bei nix-env/nix profile, und alte Generationen können aggressiver bereinigt werden.
      Die Strategie besteht darin, immer einen deklarativen und reproduzierbaren Weg zur Wiederherstellung des Bereinigten sicherzustellen und dann mit Heuristiken wie freiem Speicherplatz, Alter, kürzlicher Nichtnutzung und geringer Nutzungshäufigkeit zu vermeiden, dass die Festplatte voll läuft.
    • Ich frage mich, wie das im Vergleich zu Docker oder Bazel ist.
      Umgekehrt hatte ich dieses Problem mit Nix noch nie. Es erklärt klar, wie man Garbage Cleanup macht, und man kann leicht untersuchen, was noch übrig ist und warum.
      Dass es nicht standardmäßig aktiviert ist, liegt daran, dass es wie andere Garbage Collectors störend sein kann und es keine Policy gibt, die für alle passt.
      Wenn es am Ende zu viele GC-Roots gibt, muss man Entscheidungen treffen.
    • Nix unterstützt Garbage Collection.
      Bei jeder Computernutzung passieren im Hintergrund tausende absurd komplexe Dinge; ich sehe nicht ganz, warum gerade die Abstraktion von Nix eine Sonderbehandlung bekommen sollte.
    • Bei der Arbeit haben wir dasselbe Problem mit Bazel. Nach ein paar Monaten geht den Entwicklungsmaschinen der Speicherplatz aus.
    • Man kann Nix Garbage Collection so konfigurieren, dass sie alle 30 Minuten läuft.

  • Glückwunsch zum Release. Ich mag Nix wirklich sehr, räume aber auch ein, dass die Onboarding-Erfahrung bestenfalls schlecht und schlimmstenfalls furchtbar ist.
    Deshalb begrüße ich jeden Versuch, es zugänglicher zu machen. Eine imperative CLI kommt dem, was viele erwarten und womit sie sich wohlfühlen, deutlich näher; das halte ich für eine gute Richtung.
    Auch die Vereinfachung des Prozesses, Umgebungen an anderen Orten zu verwenden, leuchtet mir sehr ein.
    Was mir allerdings wichtig erscheint und hier fehlt, ist IDE-Integration. Eine IDE aus der Umgebung heraus über die Kommandozeile zu starten, ist für viele Kolleginnen und Kollegen nicht intuitiv, und ich habe das schon mehrfach als eigentliche Ursache realer Probleme diagnostiziert.
    Ich frage mich, wie die Geschichte aussieht, wenn man bei Bedarf auf „echtes Nix“ hinuntergehen muss. Zum Beispiel mache ich mir Sorgen, ob man bei einer etwas komplexeren Umgebung wie der Einrichtung einer Rust-Cross-Compile-Toolchain an eine Klippe gerät.
    Als Rust-Entwicklungsbeispiel: Ich musste in eine Flake einen langen shellHook einbauen, damit Rust-Analyzer korrekt funktioniert. Mich würde interessieren, wie man so etwas in Flox umsetzen kann.
    Will man solche Dinge abstrahieren? Und falls nicht, frage ich mich, wie Nutzerinnen und Nutzer ohne Nix-Kenntnisse das herausfinden sollen.
    Ich will keineswegs sagen, dass das unmöglich ist, und ich hoffe wirklich, dass es gut funktioniert, aber ich sehe den Weg noch nicht so recht.

    • Den Punkt, bei Bedarf auf „echtes Nix“ hinunterzugehen, haben wir bereits diskutiert, und wir planen, Nix selbst nutzbar zu machen, wenn zusätzliche Power gebraucht wird.
      Der aktuelle Gedanke ist, in bestimmten Feldern Flake-Referenzen zu erlauben oder Einstiegspunkte im Nix-Stil bereitzustellen.
      Das ist noch nicht veröffentlicht oder dokumentiert, daher bitte noch etwas Geduld.
      Ich stimme völlig zu, dass es eine sehr feine Linie zwischen dem Verbergen von Komplexität und dem Offenlegen von Fähigkeiten gibt.

  • Ich frage mich, welchen Vorteil es hat, Flox statt eines normalen nix-shell oder nix develop zu verwenden.

    • Ich arbeite bei Flox. Zur Beziehung mit den Nix-Tools: Unser Ziel ist es, benutzerfreundlicher zu sein.
      Man soll erfolgreich sein können, ohne die Nix-Expression-Sprache zu lernen oder die internen Strukturen von Nix zu verstehen.
      Außerdem haben wir ein gewisses Maß an Richtung und Feinschliff hinzugefügt. Zum Beispiel gibt es ein gemischtes imperatives/deklaratives Interface: Wenn man flox install && flox list ausführt, werden die Änderungen in TOML übernommen. Bei nix develop hingegen muss man eine Nix-Expression bearbeiten.
      nix develop führt in eine Bash-Shell, während flox activate in eine Bash- oder zsh-Shell wechseln kann; Unterstützung für fish wollen wir ebenfalls hinzufügen.
      Die Verwaltung von Umgebungen mit Git unterstützen wir wie die Nix-Tools, haben aber zusätzlich Möglichkeiten zum Teilen von Umgebungen eingebaut, die mit diesen Tools so nicht gehen, etwa flox push/flox pull/flox activate -r.
      Wenn man ein Konto erstellt, kann man unter https://hub.flox.dev/mkenigs/default die Pakete in meiner Umgebung sehen; mit der CLI kann man sie per flox list -r mkenigs/default ansehen und dann mit flox activate -r mkenigs/default verwenden.
      Ich halte das für deutlich leichter verdaulich, als Leuten ohne Kenntnisse der Nix-Expression-Sprache eine flake.nix zu verlinken.
    • Anders gesagt: Ich denke, einzelne Engineers sind besser damit beraten, die zugrunde liegende Technologie und die zugehörigen Tools zu lernen.
      Es ist gut möglich, dass Tools wie Flox oder devenv ihr Lebensende erreichen, nicht richtig mit nixpkgs Schritt halten oder einer der vielen Formen von Software-Verfall erliegen.
      nix develop hingegen wird bestehen bleiben, solange Nix Flakes bestehen, und es gibt auch einen Anreiz, einen Migrationspfad zur nächsten Vorgehensweise bereitzustellen.
      Noch wichtiger: Alle Abstraktionen sind undicht. Die Flox-CLI mag sauberer aussehen, aber am Ende wird man Nix lernen müssen, um sie effektiv zu nutzen.
      Ich frage mich, warum man doppelt so viel lernen sollte wie nötig.
    • Oder es gibt auch https://devenv.sh.

  • Ich frage mich, wie es sich im Vergleich zum bestehenden Devbox-Projekt (https://www.jetpack.io/devbox) schlägt.
    Mich würde auch interessieren, ob Flox eine optionale Cloud-Lösung hat, ob man bestimmte Versionen von Nix-Paketen installieren kann und wie betriebssystemspezifische Abhängigkeiten behandelt werden.
    Ich nutze solche Tools seit fünf Jahren und frage mich, was Flox gegenüber dem bereits Vorhandenen neu mitbringt.

  • Ich verstehe wirklich nicht, warum man das statt normalem Nix verwenden sollte. Kann das jemand erklären?

    • Ich will pro Projekt einfach nur saubere und reproduzierbare Umgebungen. Ich habe ein paar Mal versucht, in Nix einzusteigen, aber Nix macht so viele verschiedene Dinge, dass ich jedes Mal überwältigt war.
      Das hier wirkt auf mich 100-mal einfacher.
    • Wir verstehen, dass Nix viele Probleme löst, und wir haben tatsächlich auf diese Fähigkeiten gesetzt. Deshalb haben wir auch viel Arbeit in Nix selbst gesteckt.
      Aber weil Nix von den Grundprinzipien an sehr allgemein aufgebaut wurde, ist die Lernkurve ziemlich steil.
      Flox ist ein Tool, das den Problemraum eingrenzt und spezialisierte Abstraktionen und Interfaces bereitstellt, damit man die Fähigkeiten von Nix nutzen kann, ohne ab dem ersten Tag Nix-Experte sein zu müssen.
    • Es ist viel einfacher, Kolleginnen und Kollegen von flox oder devenv zu überzeugen als von Nix.

  • Ich interessiere mich sehr für reproduzierbare Entwicklungsumgebungen und nutze auf der Arbeit seit Jahren erfolgreich Dev-Container.
    Vor etwa einem Jahr habe ich von Nix gehört und war anfangs sehr gespannt, weil das Versprechen großartig klang, aber der Onboarding-Prozess war für mich furchtbar.
    Ich habe eine klare Vorstellung von der Entwicklungsumgebung, die ich bauen möchte, aber beim Ansatz fühlt es sich immer so an, als würde mir etwas entgehen.
    Ich freue mich, dass ein neues Tool erscheint, das die gesamte Erfahrung verbessern will, und hoffe, dass es irgendwann Klick macht, wenn ich weiter dranbleibe.
    Mich würde interessieren, in welchem Moment Nix bei dir „Klick“ gemacht hat.

    • Danke für die Frage. Das ist ein Thema, über das man bei einem Bier ausführlich reden sollte, wenn du mal in der Bay Area bist.
      Hast du vielleicht das Microservices-Video gesehen? https://www.youtube.com/watch?v=y8OnoxKotPQ
      Damals leitete ich bei Facebook das Developer-Products-Team und startete ein Projekt, das Remote-Funktionen in die lokale Entwicklung einbringen sollte.
      Tausende Entwickler warteten jeweils 45 Minuten auf Cold Builds.
      Einer der frühen Schritte war, den gesamten Softwareentwicklungs-Lebenszyklus aufzuzeichnen, um herauszufinden, welche Teile der Toolchain wir neu bauen mussten.
      Wenn man sich das Whiteboard gegen Ende des Videos ansieht, wird einem klar: In dem Moment, in dem wir visualisierten, wie komplex wir alles gemacht hatten, dachten wir: „So kann es unmöglich sein, wie wir arbeiten.“

  • Als ich Nix zuletzt ausprobiert habe, gab es viel Verwirrung um flakes
    Manche Tutorials empfahlen sie, andere sagten, sie seien noch in Entwicklung; ich frage mich, ob sich die Lage verbessert hat

    • Ich denke schon. Fast alle, wenn nicht alle hier aufgelisteten Lösungen scheinen intern flakes zu verwenden: https://news.ycombinator.com/item?id=39696038
      Ich denke, die Probleme mit flakes kommen aus zwei Richtungen
      Zum einen tragen sie seit fast fünf Jahren das Label experimental, was neue Nutzer verwirrt, obwohl sie in der Praxis fast überall allgemein verwendet werden
      Zum anderen scheint es zwischen https://determinate.systems/ und langjährigen Nix-Nutzern bzw. -Entwicklern böses Blut zu geben. Determinate Systems wird offenbar vorgeworfen, Nix zu seinem eigenen Vorteil zu nutzen, ohne Beiträge zurückzugeben
      Soweit ich es verstehe, hat Determinate Systems flakes eingeführt, und deshalb gibt es wohl bei einigen Widerstand
      Unterm Strich haben fast alle flakes übernommen, und Guides, die sie nicht verwenden, sind wahrscheinlich meist veraltet
      Zugehöriger Link: https://discourse.nixos.org/t/introducing-flakehub/32044
    • Ich kenne heutzutage niemanden, der davon abrät, flakes zu verwenden
      Das Label „experimental“ bezieht sich eher auf API-Stabilität als auf Reifegrad oder Bugs
      In bestimmten Situationen kann es Performance-Probleme geben, aber es gibt Workarounds, und an einer dauerhaften Lösung wird ebenfalls gearbeitet
      Trotzdem nutze ich flakes zu Hause und bei der Arbeit intensiv
    • Hinweis: Plan zur schrittweisen Stabilisierung der neuen CLI und von Flakes https://github.com/NixOS/rfcs/pull/136

  • Ich habe Flox gestern Abend unter macOS ausprobiert und gesehen, dass es, getrennt von dem Nix, das Nix-Darwin unter /run/current-system/sw/bin verwaltet, Nix im Standardprofil installiert und diese Kopie nach /usr/local/bin symlinkt
    Es gab auch keine Hinweise für bestehende Nix-Nutzer, also NixOS-Nutzer oder Nutzer anderer Distributionen, die Nix bereits installiert haben, für die es aber kein von Flox unterstütztes Distributionspaketformat gibt
    Ich frage mich, ob das daran liegt, dass Flox ein Drittanbieter-Profilmanager für Nix ist und deshalb auf Dinge wie das instabile Nix-profile-manifest-Format angewiesen ist, oder ob es in der Praxis mit verschiedenen Nix-Versionen nutzbar ist, aber nur nicht getestet wurde
    Ich würde auch gern wissen, ob eine Nix-basierte Flox-Installation als später zu unterstützende Funktion betrachtet wird
    Außerdem hieß es, fish-Support komme noch; kannst du sagen, wo die Shell-Integration des Unterbefehls activate tatsächlich im Flox-Source oder in der Konfiguration liegt
    Während ich auf offiziellen fish-Support warte, wollte ich provisorisch etwas mit fenv zusammenstecken, aber selbst nach Durchsehen der Installation und des Sourcecodes habe ich keine gute Stelle zum Einhängen gefunden

    • Du scheinst die Tabs Nix/Generic und Nix/NixOS auf https://flox.dev/docs/install-flox/ übersehen zu haben. Ich bin gespannt, ob das den von dir genannten Fall der parallelen Nutzung abdeckt
      Der derzeit beste Weg, fish zu verwenden, ist meiner Meinung nach FLOX_SHELL=zsh flox activate -- fish. Aliasse werden nicht unterstützt, aber das meiste sollte funktionieren
      Ich frage mich auch, ob du wirklich den Source hacken willst oder nur die Struktur verstehen möchtest, um einen Workaround zu bauen
      In Shells, die nicht bash oder zsh sind, wird ungefähr hier ein Fehler ausgegeben: https://github.com/flox/flox/blob/9e18a3ceaa185006bae95a4827...
      Wenn du es selbst reparieren möchtest, gebe ich gern noch mehr Hintergrund dazu