haskell - para - ¿Cuál es la diferencia entre Cabal y Stack?

update haskell (3)

Ayer me enteré de una nueva herramienta de Haskell llamada Stack . A primera vista, parece que hace el mismo trabajo que Cabal. Entonces, ¿cuál es la diferencia entre ellos? ¿Es stack un reemplazo para Cabal? ¿En qué casos debo usar Stack en lugar de Cabal? ¿Qué puede hacer Stack que Cabal no pueda?

¿Es stack un reemplazo para Cabal?

Si y no.

¿En qué casos debo usar Stack en lugar de Cabal? ¿Qué puede hacer Stack que Cabal no pueda?

Dado que Stack usa los paquetes de apilamiento seleccionados de manera predeterminada , se sabe que los paquetes se compilan juntos. En Cabal, existe la posibilidad de que te golpeen con el infierno cabal. Stack también almacena en caché localmente su paquete, para que no compile todo desde cero cuando use ese paquete (o su dependencia transitiva) la próxima vez. Tenga en cuenta que también está previsto el uso de paquetes que no son de apilamiento, por lo que puede continuar incluso si un paquete no está presente en la instantánea de apilamiento.

Personalmente, me gusta Stack y recomendaría a todos los desarrolladores de Haskell que lo usen. Su desarrollo es rápido . No se preocupan (tanto) por la compatibilidad con versiones anteriores. Y tiene una experiencia de usuario mucho mejor. Y hay cosas que la stack hace que Cabal aún no proporciona:

Stack incluso descarga GHC por usted y lo mantiene en una ubicación aislada.
Soporte Docker (que es muy conveniente para implementar sus aplicaciones Haskell)
Script de Haskell reproducible : puede identificar la versión de un paquete y obtener la garantía de que siempre se ejecutará sin ningún problema.
Posibilidad de hacer una stack build --fast --file-watch . Esto se reconstruirá automáticamente si cambia los archivos locales presentes. Usarlo junto con la opción --pedantic es un --pedantic para mí.
~~Capacidad para especificar el repositorio externo de git como una dependencia.~~ ~~Comenzando con Cabal 2.4 , cabal también admite repositorio externo de git como una dependencia.~~ (Un punto a tener en cuenta aquí es que Stack tuvo esta característica durante más de 3 años y Cabal finalmente la alcanzó).
Stack admite la creación de proyectos utilizando templates . También es compatible con sus propias plantillas personalizadas.
La pila tiene soporte de hpack incorporado. Proporciona una forma alternativa (IMO, una mejor) de escribir archivos cabal usando el archivo yaml, que es más ampliamente utilizado en la industria.
Intero tiene una experiencia fluida cuando trabaja con Stack .

Hay una buena publicación de blog que explica la diferencia: ¿Por qué Stack no es Cabal?

En lo que sigue, me referiré a las dos herramientas que se comparan como cabal-install y stack . En particular, usaré cabal-install para evitar confusiones con la biblioteca Cabal , que es la infraestructura común utilizada por ambas herramientas. En términos generales, podemos decir que cabal-install y stack son frontends para Cabal , y las diferencias clave entre ellos se reducen a cuáles son los flujos de trabajo predeterminados:

De manera predeterminada, cabal-install , cuando se le pida que .cabal un proyecto, examinará las dependencias especificadas en su archivo .cabal y usará un solucionador de dependencias para descubrir (si es posible) un conjunto de paquetes y versiones de paquetes que lo satisfagan. Este conjunto se extrae de Hackage en su conjunto: todos los paquetes y todas las versiones, pasadas y presentes. Una vez que se encuentra un plan de compilación factible, la versión elegida de las dependencias, por defecto, se instalará y registrará en una única base de datos de paquetes instalados en algún lugar de ~/.cabal .
stack , por otro lado, primero mirará el campo de resolver de stack.yaml . Ese campo generalmente especifica una instantánea de Stackage , que es un subconjunto de paquetes de Hackage con versiones fijas que se sabe que son compatibles entre sí. stack intentará, de forma predeterminada, satisfacer las dependencias utilizando exclusivamente lo que proporciona la instantánea. Los paquetes instalados desde una instantánea se registran en bases de datos diferentes y aisladas, y se mantienen instalaciones separadas de GHC para dar cuenta de lo que requieren las instantáneas. Este enfoque intercambia un poco de flexibilidad por la garantía de que no habrá incompatibilidades de versión entre los paquetes instalados (un problema común cuando se usa una base de datos de un solo paquete con cabal-install , por las razones discutidas en este artículo ), así como que siempre es posible para averiguar las versiones exactas de las dependencias que se utilizarán para construir un proyecto (que es útil tanto para garantizar compilaciones reproducibles de proyectos completos como para especificar fácilmente dependencias de scripts .hs independientes sin un archivo .cabal complementario).

Tenga en cuenta que la descripción anterior cubre los flujos de trabajo predeterminados para cada herramienta. La mayor parte de lo que stack puede hacer se puede lograr de alguna manera (posiblemente menos conveniente) con cabal-install al salir de los valores predeterminados, y viceversa. En particular:

cabal-install admite bases de datos de paquetes aisladas para cada proyecto a través del comando cabal sandbox , aunque a diferencia de las instantáneas de pila y pila no hay posibilidad de compartir paquetes instalados entre proyectos. También es posible arreglar las versiones de las dependencias que se usarán para las compilaciones independientemente de .cabal , a través del .cabal cabal freeze . (Una característica de pila relacionada sin análogo de instalación de cabal es la administración de instalaciones de GHC separadas, es decir, la stack setup ).
los proyectos de pila pueden usar paquetes que no están disponibles en la instantánea de Stackage que se usa al configurar los campos apropiados en stack.yaml (detalles extra-deps para paquetes disponibles de Hackage pero no de Stackage, y packages con una location personalizada para paquetes que no están en Hackage). Estos paquetes que no son de Stackage se instalan por proyecto, con aislamiento de las instantáneas. También hay un comando de stack solver , que realiza la resolución automática de dependencias para dependencias de Hackage (es decir, no Stackage).

En una nota final, vale la pena mencionar que el soporte para compilaciones locales de estilo Nix se está agregando a cabal-install como una forma alternativa de mitigar los conflictos de versión que es potencialmente más conveniente que la cabal sandbox . Esta característica está disponible, como versión preliminar, de cabal-install 1.24.

Por lo que puedo deducir de las preguntas frecuentes, parece que Stack usa la biblioteca Cabal, pero no el binario cabal.exe (más correctamente conocido como cabal-install). Parece que el objetivo del proyecto es el sandboxing automático y evitar el infierno de la dependencia.

En otras palabras, usa la misma estructura de paquete de Cabal, solo proporciona un front-end diferente para administrar estas cosas. (¡Yo creo que!)