Muchos desarrolladores enfrentaron un problema con los paquetes infiernos en su estación de trabajo. Después de un par de meses con experimentos, incluidos diferentes idiomas y cadenas de herramientas, instalé Elixir, Haskell-stack, Node.js / NVM y otras cosas. La mayoría de las cosas emocionantes suceden cuando necesita diferentes versiones del mismo paquete para diferentes proyectos. La humanidad ya inventó una solución diferente para crear un entorno aislado y cambiarlos cuando sea necesario. Estamos utilizando NVM para administrar las versiones de Node.js, Python Virtual Env para seleccionar las versiones de Python o Docker para crear un SO dentro de un SO. Pero ninguna de las soluciones satisface todos mis requisitos para el entorno de desarrollo aislado.
Introducción a los requisitos para administrar la herramienta de entorno aislado
Era una fría tarde de otoño. Estaba sentado en la sala de mi cocina y pensé en el aislamiento perfecto para el espacio de trabajo del proyecto con sus dependencias. En realidad, no lo hice, pero el párrafo debería tener una introducción.
Después de eso, escribí los siguientes criterios para mi herramienta de aislamiento perfecta:
- Debe cubrir diferentes idiomas y paquetes: no solo Node.js, Python o Haskell.
- Sin virtualización Somos demasiado jóvenes para toda esta mierda. Ahorremos nuestro tiempo.
- Todos los paquetes de espacio de trabajo deben ser fáciles de eliminar.
- Todos los entornos del espacio de trabajo deberían ser fáciles de eliminar.
- Mi IDE debería estar trabajando con todo esto sin llamar a Molfars desde las montañas de los Cárpatos ucranianos.
Necesitamos una taza de té y Google, pero una taza de té al principio
Recuerdo que una vez que leí sobre el administrador de paquetes declarativo que puede producir un entorno aislado y administrar todas las dependencias del sistema y las dependencias del proyecto Haskell también.
Cinco minutos buscando en Google, 30 minutos de lectura y 1 hora de prueba me permiten descubrir que la herramienta actual es todo lo que necesito. Todo lo que necesito es amor. Pero para, es otra canción. Todo lo que necesito es Nix.
Comparemos los requisitos que escribí anteriormente de las características reales de Nix.
- Compatible con macOS: sí.
- Cubre diferentes idiomas y paquetes, sí.
- Sin virtualización, realmente sin virtualización.
- Todos los paquetes de espacio de trabajo deberían ser fáciles de eliminar, tal vez sí, pero no sé cómo.
- Mi IDE debería estar trabajando con todo esto, no. No hay forma de integrar Nix Environment a Visual Studio Code.
Alerta de spoilerFue hace mucho tiempo. Cuando la tarde de otoño era fría, te dije, ¿te acuerdas? Pero hoy es una tarde completamente diferente. Es otoño cálido y todos mis problemas desaparecieron.
Ayudate a ti mismo. Escribir la extensión del código de Visual Studio
La extensión lo ayuda a integrar VS Code y Nix-shell juntos.
Soy demasiado vago para escribir este capítulo desde cero, por lo que el texto a continuación es copiar / pegar desde README.md oficial desde mi extensión.
Empezando
- En primer lugar, debe instalar el administrador de paquetes Nix .
- Reinicie VS Code para asegurarse de que la ruta para ejecutar nix-shell esté configurada correctamente
- Instala la extensión
- Cree nix env config, como default.nix en la raíz del espacio de trabajo de su proyecto
- Abra la paleta de comandos (Cmd / Ctrl + Shift + P) y escriba Seleccionar entorno
- De la lista de entornos virtuales de nix, elija el que desea aplicar
Ejemplo de ejecución del proyecto Haskell
Para ejecutar su aplicación Haskell, debe instalar el compilador GHC. Para evitar la instalación global de GHC y poder usar diferentes versiones del compilador en su host, hagamos esto usando el entorno virtual nix.
Ejemplo de compilador GHC dentro de la tienda 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; }
Ahora intentemos abrir nuestro proyecto en Visual Studio Code.
Puedes ver, IDE no puede encontrar un compilador. Encienda shell.nix env.
Bingo! Todo está bien ahora.
Conclusión
Espero que el artículo te haya traído algunas ideas nuevas sobre cómo hacer tu vida más fácil y administrar tu proyecto sin caos en tu sistema de archivos.
Los beneficios de este enfoque son:- Todos los paquetes en un espacio de trabajo separado y no afectan el alcance global en contra de lo que quiere implícito
- Su IDE ve a todo el personal del espacio de trabajo y trabaja como esperaba
- Arranque simple del proyecto desde un archivo de configuración en diferentes máquinas
Nada es perfecto en nuestro mundo:- Necesito aprender un nuevo idioma para escribir archivos de configuración
- La opción Nix CLI no tiene un significado obvio y todo el tiempo cuando interactúa con las herramientas CLI necesita leer la ayuda de comandos
- Todos los lenguajes de programación tienen sus cosas para instalar bibliotecas de ecosistemas. Como NPM, Cabal, Cargo, Pip, etc. Y cuando instala este tipo de paquetes a través de Nix, corre el riesgo de no trabajar desde la caja con algunas linters, herramientas de análisis, etc.
Enlaces externos