The Haskell community has centralised this job and we can all update our dependencies on a weekly rolling schedule, together! Some larger organisations centrally managed these files, but it was never shared with the wider community. ![]() Every JVM project I’ve ever worked on has maintained an independent list of maybe-compatible libraries, that often blew up at runtime. Stackage is amazing, it is effectively a list of packages that are known (asserted by automated builds and tests) to work with each other. Stackage, on the other hand, is a list of packages, versions, and build flags, that is kept up to date by the Stackage Curators. Therefore, Hackage has the concept of Revisions, which allow trustees and maintainers to change the constraints without requiring the code to be re-published. It is not always possible to know the maximum compatible version of a dependency when publishing. This implies it won't necessarily work for foo version 1.1.0 or 2.0.0 (when/if they are released). More details in the Package Versioning Policy FAQ.įrom a practical point of view, library and application authors typically declare “ foo version 1.0.3 works for me" and get on with writing their code. Cabal already has a solution: each dependency can have a series of constraints, listing both the minimum compatible version (as per industry standards) and a maximum compatible version, which I believe is unique to Haskell. ![]() For example, the Scala community recently decided to invest in managing transitive dependencies because it has become such a problem. In most major programming languages, transitive dependencies between libraries cause painful compatibility problems. cabal files, consumed by both cabal and Stack, can also be used to produce proprietary binaries for distribution to private customers. Once on Hackage, it becomes searchable by Hoogle with docs and source code available for browsing by everybody. With this standalone description of a package, Free Software contributors can upload their applications and libraries to Hackage, the Haskell community’s central package archive. Here is an example: jaeger-flamegraph.cabal cabal files, called package descriptors, a simple hierarchy of keys and values. Both cabal and Stack are built on top of the Cabal (capitalised) library.Ĭabal reads. ![]() When we say cabal, we mean the command line tool cabal (lowercase). When I was learning Haskell, the tooling infrastructure was by far the most difficult thing to understand. Truly, both excellent tools can live together and we can get on with the business of writing beautiful Haskell together! Cabal, Hackage and Stackage I’ll also show how to build stack.yaml projects with cabal. In this letter I will explain what cabal, Stack, Hackage and Stackage are, and describe how developers can use freeze files to access Stackage curated sets from cabal builds. We must endure any cost for a truce.” - Thomas Tuegel “The Tooling War is a limiting factor to Haskell adoption. ![]() However, when build tools are mandated by management or legacy decisions, it is no longer a choice and we can become resentful of a tool that is not a good fit for our personal workflow. The State of Haskell 2018 survey results show that the community is split between cabal (aka cabal-install) and Stack as their build tool.Īlthough this split can get heated at times (duplicated effort, risk of tribalism, etc), I see it as a user choice that could lead to greater levels of happiness for every developer. Build Haskell projects with either cabal or stack.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |