Viele Entwickler hatten ein Problem mit Paketen auf ihrer Workstation. Nach ein paar Monaten mit Experimenten, einschließlich verschiedener Sprachen und Toolchains, installierte ich Elixir, Haskell-Stack, Node.js / NVM und andere verschiedene Dinge. Die aufregendsten Dinge passieren, wenn Sie verschiedene Versionen desselben Pakets für verschiedene Projekte benötigen. Die Menschheit hat bereits eine andere Lösung erfunden, um eine isolierte Umgebung zu schaffen und diese bei Bedarf zu wechseln. Wir verwenden NVM zum Verwalten von Node.js-Versionen, Python Virtual Env zum Auswählen von Python-Versionen oder Docker zum Erstellen eines Betriebssystems innerhalb eines Betriebssystems. Keine der Lösungen erfüllt jedoch alle meine Anforderungen an die isolierte Entwicklungsumgebung.
Einführung in die Anforderungen für die Verwaltung von isolierten Umgebungstools
Es war ein kalter Herbstabend. Ich saß in meinem Küchenraum und dachte über die perfekte Isolation für den Projektarbeitsbereich mit ihren Abhängigkeiten nach. Eigentlich habe ich nicht, aber der Absatz sollte eine Einführung haben.
Danach habe ich die folgenden Kriterien für mein perfektes Isolationswerkzeug geschrieben:
- Sollte verschiedene Sprachen und Pakete abdecken: nicht nur Node.js, Python oder Haskell.
- Keine Virtualisierung. Wir sind zu jung für all diese Scheiße. Sparen wir unsere Zeit.
- Alle Workspace-Pakete sollten leicht zu entfernen sein.
- Alle Arbeitsumgebungen sollten leicht zu entfernen sein.
- Meine IDE sollte mit all diesen Dingen arbeiten, ohne Molfars aus den ukrainischen Karpaten anzurufen.
Wir brauchen eine Tasse Tee und Google, aber zuerst eine Tasse Tee
Ich erinnere mich, dass ich einmal etwas über den deklarativen Paketmanager gelesen habe, der eine isolierte Umgebung erstellen und alle Systemabhängigkeiten und Haskell-Projektabhängigkeiten verwalten kann.
Wenn ich fünf Minuten google, 30 Minuten lese und eine Stunde versuche, finde ich heraus, dass das aktuelle Tool alles ist, was ich brauche. Alles was ich brauche ist Liebe. Aber hör auf, es ist ein anderes Lied. Ich brauche nur Nix.
Vergleichen wir die Anforderungen, die ich oben geschrieben habe, mit den tatsächlichen Nix-Funktionen.
- Kompatibel mit MacOS - ja.
- Deckt verschiedene Sprachen und Pakete ab - ja.
- Keine Virtualisierung - wirklich keine Virtualisierung.
- Alle Workspace-Pakete sollten leicht zu entfernen sein - vielleicht ja, aber ich weiß nicht wie.
- Meine IDE sollte mit all dem Zeug arbeiten - nein. Es gibt keine Möglichkeit, Nix Environment in Visual Studio Code zu integrieren.
Spoiler AlarmEs ist lange her. Als der Herbstabend kalt war, habe ich dir gesagt, erinnerst du dich? Aber heute ist ein ganz anderer Abend. Es ist ein warmer Herbst und alle meine Probleme sind verschwunden.
Bedien dich. Schreiben der Visual Studio Code-Erweiterung
Die Erweiterung hilft Ihnen dabei, VS Code und Nix-Shell zusammen zu integrieren.
Ich bin zu faul, um dieses Kapitel von Grund auf neu zu schreiben, daher ist der folgende Text aus der offiziellen README.md-Datei meiner Erweiterung kopiert / eingefügt.
Erste Schritte
- Zunächst sollten Sie den Nix-Paketmanager installieren.
- Starten Sie VS Code neu, um sicherzustellen, dass der Pfad zur Ausführung von nix-shell ordnungsgemäß konfiguriert ist
- Installieren Sie die Erweiterung
- Erstellen Sie nix env config, wie default.nix, im Stammverzeichnis Ihres Projektarbeitsbereichs
- Öffnen Sie die Befehlspalette (Cmd / Ctrl + Shift + P) und geben Sie Select environment ein
- Wählen Sie aus der Liste der virtuellen Umgebungen von nix die aus, die Sie anwenden möchten
Beispiel für das Ausführen eines Haskell-Projekts
Um Ihre Haskell-Anwendung auszuführen, müssen Sie den GHC-Compiler installieren. Um eine globale GHC-Installation zu vermeiden und unterschiedliche Compilerversionen auf Ihrem Host verwenden zu können, verwenden Sie dazu die virtuelle Umgebung von nix.
Beispiel für einen GHC-Compiler im NIX-Store (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; }
Versuchen wir nun, unser Projekt in Visual Studio Code zu öffnen.
Sie können sehen, IDE kann keinen Compiler finden. Lassen Sie uns shell.nix env einschalten.
Bingo! Jetzt ist alles in ordnung
Fazit
Ich hoffe, der Artikel brachte Ihnen einige neue Ideen, wie Sie Ihr Leben einfacher gestalten und Ihr Projekt ohne Chaos in Ihrem Dateisystem verwalten können.
Die Vorteile dieses Ansatzes sind:- Alle Pakete befinden sich in einem separaten Arbeitsbereich und haben keinen Einfluss auf den globalen Gültigkeitsbereich
- Ihre IDE sieht alle Mitarbeiter im Arbeitsbereich und arbeitet wie erwartet
- Einfaches Projekt-Bootstrapping von einer Konfigurationsdatei auf verschiedenen Rechnern
Nichts ist perfekt in unserer Welt:- Müssen Sie eine neue Sprache lernen, um Konfigurationsdateien zu schreiben
- Die Nix-CLI-Option hat keine offensichtliche Bedeutung. Wenn Sie mit CLI-Tools interagieren, benötigen Sie die Hilfe zu Lesebefehlen
- Alle Programmiersprachen haben ihre Fähigkeiten, um Ökosystembibliotheken zu installieren. Wie NPM, Cabal, Cargo, Pip, etc. Und wenn Sie diese Art von Paketen über Nix installieren, besteht die Gefahr, dass einige Linters, Analysewerkzeuge usw. nicht mehr funktionieren.
Externe Links