Flox 1.0 – Codifier les environnements de développement open source avec Nix

 (github.com/flox)
3 points par GN⁺ 2024-03-14 | 1 commentaires | Partager sur WhatsApp
  • Flox est une plateforme d’environnements logiciels destinée aux équipes d’ingénierie, qui gère dans un seul manifeste des environnements reproductibles à l’identique, du laptop développeur à la CI et à la production
  • Elle repose sur Nix, mais la connaissance de Nix est facultative ; sa structure réduit la dérive des environnements grâce à des manifestes déclaratifs et à des entrées verrouillées cryptographiquement par hachage de contenu
  • Fonctionne sur macOS, Linux et Windows WSL2 ; permet de rechercher et d’installer plus de 120 000 paquets de Nixpkgs, ainsi que de construire et publier ses propres logiciels sous forme de paquets reproductibles
  • Le flux flox init, flox install, flox activate crée un environnement isolé par projet ; une fois activé, les outils apparaissent, puis disparaissent à la sortie, ce qui garde le système propre
  • Flox met l’accent sur la gestion du cycle de vie des environnements à l’échelle de l’organisation, avec partage via FloxHub, création d’images OCI, exécution de services, SBOM, correctifs CVE, SCA et environnements d’exécution déterministes pour agents de codage IA

Le problème que Flox cherche à résoudre

  • Flox est une plateforme qui définit un environnement de développement dans un fichier unique et permet d’exécuter le même environnement sur les laptops des développeurs, en CI et en production
  • Là où les gestionnaires de paquets traditionnels se concentrent sur l’installation de paquets sur une seule machine, Flox gère le cycle de vie des paquets et des environnements à l’échelle de toute l’organisation
  • Ses propriétés clés sont au nombre de trois
    • Déclaratif : décrit dans un seul fichier les outils, variables d’environnement et services nécessaires au projet
    • Reproductible : la même définition crée le même environnement sur tout système pris en charge
    • Composable : permet de superposer des environnements par projet, équipe ou pipeline

Utilisateurs cibles et environnements d’utilisation

  • Les équipes Platform et DevX peuvent standardiser les toolchains à l’échelle de l’organisation et étendre des environnements de référence sans imposer l’apprentissage de Nix
  • Les équipes Security et AppSec peuvent gérer les SBOM, la réponse rapide aux CVE, la provenance des dépendances et les builds reproductibles
  • Les développeurs peuvent utiliser des environnements reproductibles par projet sur macOS, Linux et Windows WSL2, avec un fonctionnement plus proche d’un environnement virtuel que d’un conteneur ou d’une VM
  • Les agents de codage IA obtiennent un environnement déterministe permettant de compiler et d’exécuter le code généré de la même manière à chaque fois
    • Les exemples visés sont Claude Code, Cursor, Copilot et Codex

Reproductibilité et sécurité de la chaîne d’approvisionnement

  • Les environnements Flox sont définis par un manifeste déclaratif et verrouillés sur des entrées de hachage de contenu fixées cryptographiquement
  • Un même lockfile se résout en les mêmes paquets sur chaque système pris en charge, ce qui maintient les environnements identiques d’une machine à l’autre
  • Une même définition d’environnement peut être utilisée sur le laptop d’un développeur, dans le sandbox d’un agent IA, en CI et en production
  • Donne accès à plus de 120 000 paquets de Nixpkgs
  • Permet de construire ses propres logiciels depuis les sources sous forme de paquets reproductibles, puis de les publier pour toute l’équipe
  • La reproductibilité facilite la génération de SBOM, l’analyse de composition logicielle (SCA), les correctifs automatiques de vulnérabilités et de CVE, la vérification de la provenance des dépendances et les builds auditables

Installation et workflow de base

  • Le CLI Flox s’installe nativement sur macOS, Linux et Windows WSL2
    • macOS : brew install flox ou installateur .pkg
    • Linux : .deb pour Debian/Ubuntu, .rpm pour Fedora/RHEL
    • Windows : utilisation des paquets Linux dans WSL2
  • Le flux d’utilisation de base consiste à créer un environnement dans un projet, installer les paquets nécessaires, puis activer l’environnement
    • flox init : crée un environnement dans le projet
    • flox install python3 nodejs : installe des paquets dans l’environnement
    • flox activate : entre dans l’environnement
  • L’exemple du README montre que, dans l’environnement activé, python3 --version renvoie Python 3.13.13 et node --version renvoie v24.15.0
  • En quittant l’environnement, les outils installés disparaissent, ce qui évite les conflits entre projets et garde le système propre

Fonctionnalités principales

  • Create : créer un environnement déclaratif à côté du code avec flox init et l’activer automatiquement
  • Search : trouver plus de 120 000 paquets de Nixpkgs avec flox search
  • Share : permettre aux membres de l’équipe de récupérer à l’identique un environnement de référence unique présent sur FloxHub avec flox push / flox pull
  • Containerize : transformer un environnement Flox en image OCI sans Dockerfile avec flox containerize
  • Build & publish : construire ses propres logiciels sous forme de paquets reproductibles et les publier à l’équipe avec flox build / flox publish
  • Services : exécuter des bases de données, files de messages et processus d’arrière-plan comme partie intégrante de l’environnement avec flox services start ; ils démarrent à l’activation et s’arrêtent à la sortie
  • Configure : définir déclarativement les variables d’environnement, hooks de shell et scripts d’activation dans manifest.toml
  • AI-ready : via flox-agentic, permettre aux agents de codage IA de compiler et d’exécuter avec les mêmes dépendances à chaque exécution

Positionnement pour les utilisateurs de Docker et de Nix

  • Flox n’est pas une technologie de conteneurs et ne remplace pas Docker
  • Avec Docker, le packaging et l’isolation par conteneur sont souvent mêlés ; Flox considère qu’il faut séparer le packaging logiciel du mode d’isolation choisi
  • Les environnements Flox fonctionnent de la même manière sur bare metal, VM et conteneur
  • flox containerize crée une image OCI contenant l’environnement logiciel, utilisable avec Docker, Kubernetes et d’autres runtimes de conteneurs
  • Pour les utilisateurs de Nix, Flox n’est pas un remplaçant mais un outil supplémentaire
    • Fournit FloxHub, un service central pour les environnements collaboratifs et le partage de paquets
    • Regroupe hooks d’activation, services et profils shell dans un seul fichier TOML déclaratif

Origine et ressources de support

  • Flox est issu d’un déploiement Nix d’entreprise à grande échelle du D.E. Shaw group, utilisé pour rendre Nix accessible dans de grandes organisations d’ingénierie
  • Ressources associées
    • Documentation : tutoriels, références, guides
    • FloxHub : exploration et partage d’environnements
    • Discourse : questions, discussions, annonces
    • Blog : articles approfondis et workflows
    • VS Code extension : gestion des environnements Flox dans l’éditeur
  • Les demandes relatives à la sécurité sont à adresser à security@flox.dev
  • La licence de Flox CLI est GPLv2

À lire aussi

1 commentaires

 
GN⁺ 2024-03-14
Avis de Hacker News

  • Ron, félicitations pour le lancement. Je me demande quel est le modèle économique
    Il y a un CEO, une entreprise, des employés, et d’après Crunchbase il semble que vous ayez levé 24 millions de dollars, mais je ne trouve aucune information de prix sur la landing page ni dans la documentation
    Même en me connectant à FloxHub avec mon profil GitHub, je ne vois pas d’option de paiement ; je serais curieux de connaître vos plans

    • Merci pour la remarque. Le format gratuit et open source que nous avons annoncé aujourd’hui est l’une des grandes raisons pour lesquelles nous avons lancé Flox, et nous comptons y ajouter beaucoup plus de choses
      Le client open source annoncé aujourd’hui et le service FloxHub de partage d’environnements resteront gratuits à vie
      Par la suite, nous voulons proposer des catalogues logiciels privés plus puissants, construits par-dessus le Flox Catalog de base
      Si vous avez besoin de distribuer vos propres artefacts, ou de versions modifiées de paquets open source dans Flox, nous prévoyons de vous permettre de créer facilement votre propre catalogue pour compléter le Flox Catalog, qui restera toujours gratuit
      À long terme, nous voulons vendre des solutions d’entreprise sous forme d’abonnements et de services afin d’aider les entreprises à mieux gérer leurs chaînes d’approvisionnement logicielles vastes et fragmentées, et il nous semble raisonnable que les entreprises contribuent au coût de développement d’outils adaptés à leurs besoins
    • Je suis surpris qu’ils aient levé 24 millions de dollars. Je ne vois pas vraiment le chemin vers une sortie à 2,4 milliards de dollars avec ça, mais bonne chance

  • Je bloque à chaque fois que je vois dans le README une formulation du genre « Nix rendu plus facile pour les nouveaux utilisateurs », ou des expressions similaires
    Je pense être plutôt compétent, mais en utilisant Nix je n’ai jamais eu une seule fois l’impression que « c’était facile »
    J’adore les concepts de Nix, mais l’expérience utilisateur est épouvantable. Peut-être que cet outil résout ce problème, mais pour en arriver là, il faut se débattre avec une documentation quasi inexistante, des approches déjà obsolètes et modifier sa configuration sans fin, ce qui est très frustrant
    Quoi qu’il en soit, chaque fois que je vois quelque chose lié à Nix, je me dis : « vivement le jour où ce sera plus simple »

    • Si tu parles de la phrase « Flox a commencé au sein du groupe D. E. Shaw lors de l’adoption de Nix, et a rapidement prouvé sa valeur en rendant Nix plus accessible aux nouveaux utilisateurs », je la comprends plutôt à l’inverse de ton interprétation
    • Cette phrase ne veut pas dire que Nix est facile pour les nouveaux utilisateurs, mais plutôt que Flox rend Nix plus facile
    • Exactement la même expérience. J’ai pas mal bricolé avec NixOS pendant assez longtemps, mais je n’ai jamais réussi à me sentir à l’aise avec .nix ou les flakes
      Les concepts de base me sortaient sans cesse de la tête, et chaque fois que je devais configurer quelque chose de nouveau, je devais tout rechercher à nouveau ; au final, j’ai abandonné
      Le débogage des problèmes est aussi difficile, et pour comprendre ce qui ne va pas il faut fouiller dans des commandes très spécifiques et un système de fichiers infernal
      J’aime les concepts, mais dans la pratique j’ai l’impression que ça me met beaucoup trop de bâtons dans les roues
    • J’aime Nix et j’ai même contribué pas mal de paquets au dépôt nix, mais je ne pourrais jamais dire que c’est facile
      Avec mon bagage en Haskell, ça me paraît plus familier, mais la syntaxe elle-même n’est pas intuitive pour les nouveaux utilisateurs
    • Tout à fait d’accord. On voit les avantages, mais la courbe d’apprentissage initiale est incroyablement raide
      C’est un peu comme quand on apprend Rust, donc c’est aussi amusant

  • Le problème central des produits du type « la puissance de Nix sans la courbe d’apprentissage », c’est qu’en coulisses il y a toujours Nix et /nix/store, et que Nix, par conception, ne le nettoie pas automatiquement
    Quand les utilisateurs essaient un outil qui leur cache Nix, leur disque finit par se remplir, et comme ils ne savent pas comment réduire l’espace occupé, difficile d’appeler ça convivial
    C’est différent si l’utilisateur sait qu’il installe Nix et passe par un apprentissage : il peut alors se construire un modèle mental de ce qu’est /nix/store et de la façon de le gérer
    Je me demande comment vous comptez gérer cette complexité sous-jacente

    • Si l’on prend en charge les rollbacks et l’historique, le disque finit forcément par se remplir. Dans Nix, plusieurs racines de GC pointent généralement vers des profils et des paquets, ce qui empêche de les nettoyer
      Les environnements de Flox ne sont pas de simples liens symboliques, mais un format déclaratif, avec en interne des flakes ; ils peuvent donc être supprimés puis reproduits si nécessaire
      La collecte des déchets est donc moins destructrice qu’avec nix-env/nix profile, et l’on peut nettoyer plus agressivement les anciennes générations
      La stratégie consiste à garantir en permanence une méthode déclarative et reproductible pour restaurer ce qui a été nettoyé, puis à éviter que le disque se remplisse à l’aide d’heuristiques comme l’espace disponible, l’âge, l’absence d’utilisation récente ou une faible fréquence d’utilisation
    • Je me demande comment ça se compare à Docker ou Bazel
      À l’inverse, je n’ai jamais rencontré ce problème avec Nix. La méthode de nettoyage des déchets est clairement expliquée, et il est facile d’inspecter ce qui reste et pourquoi
      Si ce n’est pas activé par défaut, c’est parce que, comme les autres garbage collectors, cela peut être gênant, et qu’aucune politique ne convient à tout le monde
      Au final, s’il y a trop de racines de GC, il faut prendre une décision
    • Nix prend en charge la collecte des déchets
      Chaque fois qu’on utilise un ordinateur, des milliers de choses incroyablement complexes se produisent en coulisses ; je ne comprends pas très bien pourquoi l’abstraction de Nix devrait être traitée comme un cas à part
    • Au travail, on a le même problème avec Bazel. Après quelques mois, les machines de développement manquent d’espace disque
    • Il suffit de configurer la collecte des déchets de Nix pour qu’elle s’exécute toutes les 30 minutes

  • Félicitations pour le lancement. J’aime beaucoup Nix, mais je reconnais aussi que l’expérience d’onboarding est, au mieux, mauvaise, et au pire, atroce
    Donc toute tentative de le rendre plus accessible est bienvenue. Une CLI impérative est beaucoup plus proche de ce que beaucoup de gens attendent et trouvent confortable, donc je pense que c’est une bonne direction
    Je suis aussi tout à fait d’accord avec l’idée de simplifier l’utilisation d’environnements venant d’ailleurs
    En revanche, un point qui me semble important mais que je ne vois pas, c’est l’intégration avec les IDE. Lancer l’IDE depuis la ligne de commande à l’intérieur de l’environnement n’est pas intuitif pour beaucoup de collègues, et j’ai diagnostiqué plusieurs fois que c’était la cause profonde de vrais problèmes
    Je me demande aussi comment se passe le retour au « vrai Nix » quand c’est nécessaire. Par exemple, avec un environnement un peu plus complexe pour configurer une toolchain Rust de cross-compilation, j’ai peur qu’on tombe d’une falaise
    Comme exemple de développement Rust, j’ai dû mettre un long shellHook dans un flake pour que Rust-Analyzer fonctionne correctement ; je me demande comment ce genre de configuration pourrait se faire dans Flox
    Je me demande si l’objectif est d’abstraire ce genre de choses, et sinon, comment un utilisateur qui ne connaît pas Nix pourrait les découvrir
    Je ne dis absolument pas que c’est impossible, et j’espère vraiment que ça marchera bien, mais je ne vois pas encore très bien comment

    • La partie où l’on redescend vers le « vrai Nix » quand c’est nécessaire a déjà été discutée, et l’idée est de permettre d’utiliser Nix lui-même quand on a besoin de puissance supplémentaire
      Pour l’instant, nous envisageons soit d’autoriser des références à des flakes dans certains champs, soit de fournir un point d’entrée de style Nix
      Ce n’est pas encore public ni documenté, donc il faudra patienter un peu
      Je suis entièrement d’accord : il y a une ligne vraiment subtile entre cacher la complexité et exposer la puissance

  • Je me demande quel est l’intérêt d’utiliser Flox plutôt qu’un nix-shell ou nix develop classique

    • Je travaille chez Flox. Pour commencer par la relation avec les outils Nix, l’objectif est d’être plus convivial
      L’idée est de permettre de réussir sans avoir à apprendre le langage d’expressions de Nix ni à comprendre ses structures internes
      Nous avons aussi ajouté un certain niveau d’orientation et de finition. Par exemple, il existe une interface hybride impérative/déclarative : si vous exécutez flox install && flox list, les changements sont répercutés dans le TOML. Avec nix develop, en revanche, il faut modifier une expression Nix
      nix develop vous fait entrer dans un shell bash, tandis que flox activate peut vous faire entrer dans un shell bash ou zsh, et nous prévoyons d’ajouter le support de fish
      La gestion des environnements avec Git est prise en charge comme avec les outils Nix, mais nous avons aussi ajouté des modes de partage d’environnements que ces outils ne permettent pas, avec flox push/flox pull/flox activate -r
      Si vous créez un compte, vous pouvez voir les paquets de mon environnement sur https://hub.flox.dev/mkenigs/default ; et si vous avez la CLI, vous pouvez les consulter avec flox list -r mkenigs/default, puis l’utiliser avec flox activate -r mkenigs/default
      À mon avis, c’est beaucoup plus digeste pour quelqu’un qui ne connaît pas le langage d’expressions de Nix que de lui envoyer un lien vers un flake.nix
    • Autrement dit, je pense qu’un ingénieur individuel a plutôt intérêt à apprendre la technologie sous-jacente et les outils qui l’accompagnent
      Il est tout à fait possible que des outils comme Flox ou devenv arrivent en fin de vie, ne suivent pas correctement nixpkgs, ou subissent l’une des nombreuses formes de pourrissement logiciel
      À l’inverse, nix develop restera là tant que Nix Flakes existera, et aura aussi une raison de proposer une voie de migration vers la prochaine approche
      Plus important encore, toutes les abstractions fuient. Même si la CLI de Flox peut sembler plus propre, il faudra probablement apprendre Nix au final pour l’utiliser efficacement
      Je ne vois pas l’intérêt d’apprendre deux fois plus que nécessaire
    • Ou bien il y a aussi https://devenv.sh

  • Je me demande comment cela se compare au projet Devbox existant (https://www.jetpack.io/devbox)
    J’aimerais aussi savoir si Flox propose une solution cloud optionnelle, s’il permet d’installer une version précise d’un paquet Nix, et comment il gère les dépendances propres à chaque système d’exploitation
    J’utilise ce genre d’outils depuis cinq ans, et je me demande ce que Flox apporte de nouveau par rapport à ce qui existe déjà

  • Je ne comprends vraiment pas pourquoi il faudrait utiliser ça plutôt que Nix tout court ; quelqu’un peut m’expliquer ?

    • Je veux seulement des environnements propres et reproductibles pour chaque projet. J’ai essayé de me mettre à Nix plusieurs fois, mais comme Nix fait tellement de choses différentes, je me suis senti dépassé à chaque fois
      Celui-ci me paraît 100 fois plus simple
    • Nous comprenons que Nix résout beaucoup de problèmes, et nous avons réellement misé sur cette capacité. Nous avons donc aussi beaucoup investi dans Nix lui-même
      Mais Nix a été construit à partir de principes fondamentaux pour être très généraliste, ce qui rend sa courbe d’apprentissage assez raide
      Flox cherche à restreindre le périmètre du problème et à proposer des abstractions et interfaces spécialisées, afin de simplifier l’accès à la puissance de Nix sans devoir devenir expert Nix dès le premier jour
    • Il est beaucoup plus facile de convaincre des collègues d’utiliser flox ou devenv que de les convaincre d’utiliser Nix

  • Les environnements de développement reproductibles m’intéressent énormément, et au travail j’utilise avec succès des dev containers depuis plusieurs années
    J’ai découvert Nix il y a environ un an et, au début, j’étais très enthousiaste parce que la promesse était excellente, mais le parcours d’onboarding a été horrible pour moi
    L’environnement de développement que je veux créer est clair, mais j’ai toujours l’impression de rater quelque chose dans l’approche
    Je suis content de voir arriver un nouvel outil qui cherche à améliorer l’expérience globale, et j’espère qu’à force d’essayer, le déclic finira par venir
    Je me demande à quel moment Nix a vraiment « fait tilt » pour vous

    • Merci pour la question. C’est le genre de sujet dont on pourrait parler longuement autour d’une bière si vous passez dans la Bay Area
      Avez-vous vu la vidéo sur les microservices ? https://www.youtube.com/watch?v=y8OnoxKotPQ
      À l’époque, je dirigeais l’équipe produits développeurs chez Facebook, et nous avions lancé un projet visant à injecter des capacités distantes dans le développement local
      Des milliers de développeurs attendaient 45 minutes pour des builds à froid
      L’une des premières étapes consistait à cartographier l’ensemble du cycle de vie du développement logiciel, afin de déterminer quelles parties de la toolchain devaient être reconstruites
      Comme le suggère le tableau blanc vers la fin de la vidéo, c’est au moment où nous avons visualisé à quel point nous avions rendu les choses complexes que je me suis dit : « ce n’est pas possible que ce soit comme ça que nous devions travailler »

  • La dernière fois que j’ai essayé Nix, il y avait beaucoup de confusion autour des flakes
    Certains tutoriels disaient de les utiliser, d’autres disaient qu’ils étaient encore en développement, et je me demande si la situation s’est améliorée

    • Je dirais que oui. Presque toutes, voire toutes les solutions listées ici semblent utiliser les flakes en interne : https://news.ycombinator.com/item?id=39696038
      À mon avis, le problème des flakes vient de deux choses
      La première, c’est qu’ils portent le label experimental depuis près de cinq ans, ce qui déroute les nouveaux utilisateurs, alors qu’en pratique ils sont couramment utilisés presque partout
      L’autre, c’est qu’il semble y avoir de mauvaises relations entre https://determinate.systems/ et les utilisateurs·développeurs Nix de longue date. Determinate Systems semble critiqué pour utiliser Nix à son avantage sans contribuer en retour
      D’après ce que j’ai compris, Determinate Systems a introduit les flakes, et c’est pour cela que certains y résistent
      En résumé, presque tout le monde a adopté les flakes, et les guides qui ne les utilisent pas sont probablement, dans l’ensemble, anciens
      Lien connexe : https://discourse.nixos.org/t/introducing-flakehub/32044
    • Je ne connais personne qui recommande aujourd’hui de ne pas utiliser les flakes
      Le label “experimental” renvoie plutôt à la stabilité de l’API qu’au niveau de finition ou aux bugs
      Dans certains cas, il peut y avoir des problèmes de performance, mais il existe des contournements et une solution permanente est aussi en cours de développement
      Malgré tout, j’utilise beaucoup les flakes à la maison comme au travail
    • À noter : plan de stabilisation progressive du nouveau CLI et des Flakes https://github.com/NixOS/rfcs/pull/136

  • J’ai essayé Flox sur macOS hier soir, et j’ai vu qu’il installait Nix dans le profil par défaut, séparément du Nix géré par Nix-Darwin dans /run/current-system/sw/bin, puis créait un lien symbolique de cette copie vers /usr/local/bin
    Il n’y avait pas non plus d’indications pour les utilisateurs existants de Nix, c’est-à-dire les utilisateurs de NixOS ou ceux d’autres distributions qui ont déjà installé Nix mais pour lesquelles il n’existe pas de format de paquet pris en charge par Flox
    Je me demande si c’est parce que Flox est un gestionnaire de profils tiers pour Nix et dépend donc de choses comme le format instable du manifest des profils Nix, ou s’il peut en réalité être utilisé avec différentes versions de Nix mais que cela n’a tout simplement pas été testé
    J’aimerais aussi savoir si l’installation de Flox basée sur Nix est envisagée comme une fonctionnalité à prendre en charge plus tard
    Et comme il a été dit que la prise en charge de fish arrivait, pourriez-vous indiquer où se trouve réellement l’intégration shell de la sous-commande activate dans les sources ou la configuration de Flox ?
    En attendant la prise en charge officielle de fish, j’ai essayé de bricoler une solution temporaire avec quelque chose comme fenv, mais en parcourant l’installation et les sources je n’ai pas vraiment trouvé d’endroit où me brancher

    • Il semble que tu aies manqué les onglets Nix/Generic et Nix/NixOS sur https://flox.dev/docs/install-flox/. Je me demande si cela couvre bien le cas d’utilisation en parallèle dont tu parles
      À l’heure actuelle, la meilleure façon d’utiliser fish me semble être FLOX_SHELL=zsh flox activate -- fish. Les alias ne sont pas pris en charge, mais la plupart des choses devraient fonctionner
      Je me demande aussi si tu veux vraiment hacker les sources, ou si tu cherches seulement à comprendre l’architecture pour créer un contournement
      Avec un shell autre que bash ou zsh, l’erreur est émise à peu près ici : https://github.com/flox/flox/blob/9e18a3ceaa185006bae95a4827...
      Si tu veux tenter de le corriger toi-même, je serais tout à fait prêt à fournir davantage de contexte