As-tu déjà utilisé quelque chose comme virtualenv en python, bundler en ruby, cabal (avec les sandbox) en haskell ou encore bien d’autres pour d’autres langages ? Ils permettent entre autre tous de définir, pour chaque projet, l’ensemble des dépendances dont tu as besoin, et ce, de manière indépendante d’un projet à l’autre. Pour chaque projet, tu peux ainsi générer un environnement correspondant à la définition voulue.
C’est particulièrement utile si tu as de projets qui utilisent une même dépendance dans des versions différentes, ou si tu as une version de maintenance d’un projet qui utilise une librairie dans une version donnée, et la version HEAD qui nécessite une version plus récente. Tu n’a pas à installer et ré-installer la librairie dans une version et une autre en permanence quand tu bascules d’un projet à l’autre.
Outre le fait que chaque utilisateur peut effectivement installer ses propres paquets, nix est une solution qui permet de faire exactement ça, mais de manière totalement agnostique du langage de programmation que tu utilises. Qui n’a jamais eu de problème parce que une librairie python / ruby / ... nécessite une librairie C ? Le gestionnaire de paquet associé à ton langage gère pas son installation, il suppose qu’elle est là quelque part. Du coup il n’est d’aucun secours pour gérer les éventuelles questions de version de celle-ci.
C’est de mon point de vue (de dev) le plus gros intérêt que tu pourrais avoir à utiliser nix sur une distribution autre (en plus du fait que chaque utilisateur peut éventuellement installer ce dont il a besoin sans avoir la main sur l’admin du système global).
Pour les paquets, nix dispose des « recettes » de compilation / installation. Il récupère les sources là où le mainteneur lui dit de les récupérer (généralement les dépôts upstream) et compile. Pour gagner du temps, il y a un cache binaire disponible qui permet de récupérer un paquet pré-compilé si celui-ci a déjà été généré par le serveur d’intégration continue (https://hydra.nixos.org/), mais rien de grave si le paquet est absent (typiquement, si c’est un paquet bien à toi, pas géré par nixpkgs).
Enfin, nix ne remplacera pas apt/dnf, à moins de passer complètement à nixos. nix vit à côté sons gêner le gestionnaire de paquet présent, et sans que le gestionnaire ne vienne gêner nix (tout ce que nix installe est sous /nix, donc pas de conflit avec les sytèmes « classiques »).
J’espère avoir répondu à tes questions (même si j’ai plus d’un point de vue de dev que d’utilisateur « lambda »).
[^] # Re: Nix (le gestionnaire) sur d'autres distros.
Posté par lancelotsix . En réponse au journal le "style fonctionnel" en vidéos (Nix, NixOS, Haskell). Évalué à 8.
As-tu déjà utilisé quelque chose comme
virtualenven python,bundleren ruby,cabal(avec les sandbox) en haskell ou encore bien d’autres pour d’autres langages ? Ils permettent entre autre tous de définir, pour chaque projet, l’ensemble des dépendances dont tu as besoin, et ce, de manière indépendante d’un projet à l’autre. Pour chaque projet, tu peux ainsi générer un environnement correspondant à la définition voulue.C’est particulièrement utile si tu as de projets qui utilisent une même dépendance dans des versions différentes, ou si tu as une version de maintenance d’un projet qui utilise une librairie dans une version donnée, et la version HEAD qui nécessite une version plus récente. Tu n’a pas à installer et ré-installer la librairie dans une version et une autre en permanence quand tu bascules d’un projet à l’autre.
Outre le fait que chaque utilisateur peut effectivement installer ses propres paquets, nix est une solution qui permet de faire exactement ça, mais de manière totalement agnostique du langage de programmation que tu utilises. Qui n’a jamais eu de problème parce que une librairie python / ruby / ... nécessite une librairie C ? Le gestionnaire de paquet associé à ton langage gère pas son installation, il suppose qu’elle est là quelque part. Du coup il n’est d’aucun secours pour gérer les éventuelles questions de version de celle-ci.
C’est de mon point de vue (de dev) le plus gros intérêt que tu pourrais avoir à utiliser nix sur une distribution autre (en plus du fait que chaque utilisateur peut éventuellement installer ce dont il a besoin sans avoir la main sur l’admin du système global).
Pour les paquets, nix dispose des « recettes » de compilation / installation. Il récupère les sources là où le mainteneur lui dit de les récupérer (généralement les dépôts upstream) et compile. Pour gagner du temps, il y a un cache binaire disponible qui permet de récupérer un paquet pré-compilé si celui-ci a déjà été généré par le serveur d’intégration continue (https://hydra.nixos.org/), mais rien de grave si le paquet est absent (typiquement, si c’est un paquet bien à toi, pas géré par nixpkgs).
Enfin, nix ne remplacera pas apt/dnf, à moins de passer complètement à nixos. nix vit à côté sons gêner le gestionnaire de paquet présent, et sans que le gestionnaire ne vienne gêner nix (tout ce que nix installe est sous
/nix, donc pas de conflit avec les sytèmes « classiques »).J’espère avoir répondu à tes questions (même si j’ai plus d’un point de vue de dev que d’utilisateur « lambda »).