@someodd, here's a few thoughts on #haskell packaging/distribution:
Support the widest range of GHC versions, deps, and all related tools you can reasonably manage, reducing unnecessary friction.
Get your packages and their dependencies into Stackage nightly and keep them there. From there they will trickle into Stackage LTS, which is a starting point for many packaging systems.
@simonmic fantastic advice. I've been avoiding Stack and just using cabal, often with Nix. Do you feel Stack is important for being more productive and getting things released and distributed?
@someodd In short: yes. For getting things released and distributed, stack's reproducibility focus and better UX and Windows support is more useful than cabal's dynamic install plan solving.
(“#stack vs #cabal” is an old and still slightly polarising debate so be warned. In 2024 #Haskell people should be familiar with the strengths of each and keep both in their toolbox.)
Check your dependencies again, this time for security risks such as use of C libs like xz/lzma. Subscribe to the RSS feed/discourse posts of the #Haskell Security Response Team. https://discourse.haskell.org/t/-/9285
@simonmic Thank you for all this stellar advice. I will try some of it out when I try making a plugin for @dillo, since that should be a relatively small project.
@someodd Also note that the advice is about Stackage and not Stack. You can use Stackage snapshots with Cabal. E.g. you can create a cabal.project file with a line like this: import: https://www.stackage.org/lts-22.16/cabal.config. It still has a lot of rough edges, for example it is not possible to override specific constraints from the snapshots, but it is usable.
Add comment