FAQ
What is a Stable Package Set?
A Stable Package Set is a collection of package versions that all build together. While a Package Repository (such as hackage) hosts available versions of packages, a Stable Package Set identifies a selection of available versions and supplies that data as a single unit known to work together. This is useful for quickly bootstrapping projects without worrying about dependency conflicts.
How is this different from stackage?
Stackage is also a Stable Package Set solution, providing a selection of available package versions in nightly and lts manifests that build together. Stackage is intended to work with the stack build tool, where as horizon is designed from scratch to work exclusively with nix. While there are existing solutions to convert stack build plans into nix expressions, they suffer from drawbacks that horizon improves upon. Stable package sets in horizon can be self-hosted, private, and version controlled independently from their use site. This gives a number of benefits:
- Package set data can be reused easily across multiple repositories.
- The latest stable package versions can be easily read from the HEAD of the stable package set repository.
- It is straightforward to bisect issues in the stable package set itself and for repositories that consume it.
How do i use it?
Horizon provides a canonical stable package set called horizon-platform. this can be consumed as a flake input to your haskell application. For an example of how to use this, see the horizon-templates. You can also self-host your own stable package set using that repository as an example.
Are there other package sets available?
There are multiple publicly available package sets serving different purposes with different policies. They are as follows.
- horizon-core - Tracking GHC master as closely as possible, but the horizon toolchain must build.
- horizon-advance - Extension to horizon-core, tracking additional repositories earmarked for future-proofing.
- horizon-platform - Tracking GHC releases as closely as possible, serving typical application use cases such as CRUD apps.
- horizon-plutus - Tracking GHC releases as closely as possible, but plutus-tx must build.
- horizon-cardano - Tracking GHC releases as closely as possible, but cardano-node must build.
- horizon-devtools - A package set targetting haskell-language-server and commonly used devshell tools such as hlint.
- horizon-moon-base - A package set targetting print, fabrication and robotics.
- horizon-ai - A package set targetting AI tools.
- horizon-biohaskell - A package set targetting bioinformatics tools.
Does this use nixpkgs?
As Horizon uses library functions from nixpkgs to construct the package set, all horizon package sets are api compatible with package sets sourced from nixpkgs. This means you will have access to familiar functions provided by haskell package sets in nixpkgs such as override, extend, etc.
Does this use haskell.nix?
No. These plans are nix-native and do not rely either on stackage or cabal’s constraint solver.
Can I have my own package set for my organisation?
Yes! Horizon comes with tools that allow you to self host a package set at any compiler version completely privately. You can extend an existing package set provided by Horizon, or build your own from scratch. For professional support, please contact dan.firth@horizon-haskell.net.
Can I request horizon-platform support for my open source package?
Please get in touch at dan.firth@horizon-haskell.net. We will try to help where we can.