Beaucoup de développeurs ont été confrontés à un problème d'enfer des packages sur leur poste de travail. Après quelques mois d'expériences, y compris différents langages et chaînes d'outils, j'ai installé Elixir, Haskell-stack, Node.js / NVM et d'autres choses diverses. Les choses les plus excitantes se produisent lorsque vous avez besoin de différentes versions du même package pour différents projets. L'humanité a déjà inventé une solution différente pour créer un environnement isolé et les changer en cas de besoin. Nous utilisons NVM pour gérer les versions de Node.js, Python Virtual Env pour sélectionner les versions de trucs Python ou Docker pour créer un système d'exploitation à l'intérieur d'un système d'exploitation. Mais aucune des solutions ne répond à toutes mes exigences pour l'environnement de développement isolé.
Inroduction aux exigences de gestion d'un outil d'environnement isolé
C'était une froide soirée d'automne. J'étais assis dans ma cuisine et j'ai pensé à une isolation parfaite pour l'espace de travail du projet avec leurs dépendances. En fait, je ne l'ai pas fait, mais le paragraphe devrait avoir une introduction.
Après cela, j'ai écrit les critères suivants pour mon outil d'isolation parfait:
- Devrait couvrir différents langages et packages: pas seulement Node.js, Python ou Haskell.
- Pas de virtualisation. Nous sommes trop jeunes pour toute cette merde. Permet d'économiser notre temps.
- Tous les packages d'espace de travail doivent être faciles à supprimer.
- Tous les environnements d'espace de travail doivent être faciles à supprimer.
- Mon IDE devrait travailler avec tout cela sans appeler Molfars des montagnes des Carpates ukrainiennes.
Nous avons besoin d'une tasse de thé et de Google, mais d'abord une tasse de thé
Je me souviens qu'une fois que j'ai lu sur le gestionnaire de paquets déclaratif qui peut produire un environnement isolé et gérer également toutes les dépendances du système et les dépendances du projet Haskell.
Cinq minutes sur Google, 30 minutes de lecture et 1 heure d'essais me permettent de découvrir que l'outil actuel est tout ce dont j'ai besoin. Tout ce dont j'ai besoin, c'est de l'amour. Mais arrêtez, c'est une autre chanson. Tout ce dont j'ai besoin, c'est Nix.
Comparons les exigences que j'ai écrites ci-dessus à partir des fonctionnalités réelles de Nix.
- Compatible avec macOS - oui.
- Couvre différentes langues et packages - oui.
- Pas de virtualisation - vraiment pas de virtualisation.
- Tous les packages d'espace de travail devraient être faciles à supprimer - peut-être oui, mais je ne sais pas comment.
- Mon IDE devrait travailler avec tout ça - non. Il n'y a aucun moyen d'intégrer Nix Environment à Visual Studio Code.
Alerte spoilerC'était il y a longtemps. Quand la soirée d'automne était froide, je vous l'ai dit, vous vous en souvenez? Mais aujourd'hui, c'est une soirée complètement différente. C'est un automne chaud et tous mes problèmes ont disparu.
Aide-toi. Écriture de l'extension de code Visual Studio
L'extension vous aide à intégrer VS Code et Nix-shell ensemble.
Je suis trop paresseux pour écrire ce chapitre à partir de zéro, donc le texte ci-dessous est copié / collé à partir du fichier README.md officiel de mon extension.
Pour commencer
- Tout d'abord, vous devez installer le gestionnaire de paquets Nix .
- Redémarrez VS Code pour être sûr que le chemin pour exécuter nix-shell est configuré correctement
- Installez l'extension
- Créez la configuration nix env, comme default.nix dans la racine de votre espace de travail de projet
- Ouvrez la palette de commandes (Cmd / Ctrl + Shift + P) et tapez Sélectionner l'environnement
- Dans la liste des environnements virtuels nix, choisissez celui que vous souhaitez appliquer
Exemple d'exécution du projet Haskell
Pour exécuter votre application Haskell, vous devez installer le compilateur GHC. Pour éviter l'installation globale de GHC et pouvoir utiliser différentes versions de compilateur dans votre hôte, faisons cela en utilisant l'environnement virtuel nix.
Exemple de compilateur GHC dans le magasin NIX (shell.nix):
{ nixpkgs ? import <nixpkgs> {} }: let inherit (nixpkgs) pkgs; inherit (pkgs) haskellPackages; haskellDeps = ps: with ps; [ base lens mtl random ]; ghc = pkgs.haskell.packages.ghc864.ghcWithPackages haskellDeps; nixPackages = [ ghc pkgs.gdb haskellPackages.cabal-install ]; in pkgs.stdenv.mkDerivation { name = "snadbox-haskell-workspace"; buildInputs = nixPackages; }
Essayons maintenant d'ouvrir notre projet dans Visual Studio Code.
Vous pouvez voir, IDE ne peut pas trouver de compilateur. Allons sur shell.nix env.
Bingo! Tout va bien maintenant.
Conclusion
J'espère que l'article vous a apporté de nouvelles idées sur la façon de vous faciliter la vie et de gérer votre projet sans chaos dans votre système de fichiers.
Les avantages de cette approche sont:- Tous les packages dans un espace de travail séparé et n'affectent pas la portée globale par rapport à ce que vous voulez implicite
- Votre IDE voit tout le personnel de l'espace de travail et travaille comme prévu
- Démarrage de projet simple à partir d'un fichier de configuration sur différentes machines
Rien n'est parfait dans notre monde:- Besoin d'apprendre une nouvelle langue pour écrire des fichiers de configuration
- L'option Nix CLI n'a pas de signification évidente et tout le temps lorsque vous interagissez avec des outils CLI, vous avez besoin de l'aide de la commande de lecture
- Tous les langages de programmation ont leur truc pour installer des bibliothèques d'écosystème. Comme NPM, Cabal, Cargo, Pip, etc. Et lorsque vous installez ce type de packages via Nix, vous risquez de ne pas travailler à partir de la boîte certains linters, d'analyser les outils, etc.
Liens externes