haskell
Main channel vs vanilla
Continuing the discussion from #166.
How to determine the set of patches/fixes applied
For tools whose binaries are available in both main and vanilla channels,
say HLS 2.5.0.0, what are the differences in terms of the specific
"patches/fixes" (as stated in the README.md) that are applied to main? How
would an end-user of ghcup determine that?
Which takes precedence
~~If one were to enable the vanilla channel in addition to the main via
below, which channel would be given priority when installing tools whose
binaries are available in both channels?~~
ghcup config add-release-channel https://raw.githubusercontent.com/haskell/ghcup-metadata/master/ghcup-vanilla-0.0.8.yaml
Answering the above myself: ^ reading the source of config.yaml in ghcup-hs,
it's clear that later entries would win. I.e, in the example above vanilla
would take precedence over main. From config.yaml source:
# Where to get GHC/cabal/hls download info/versions from. This is a list that performs
# union over tool versions, preferring the later entries.
Thank you to both the upstream and ghcup maintainers for their continued efforts.
For tools whose binaries are available in both main and vanilla channels, say HLS 2.5.0.0, what are the differences in terms of the specific "patches/fixes" (as stated in the README.md) that are applied to main? How would an end-user of ghcup determine that?
Source code patches are communicated via post-install messages with links. See
https://github.com/haskell/ghcup-metadata/blob/a6c8849dcb9358beadadbe7217a7ad108b150fd0/ghcup-0.0.8.yaml#L4596-L4602
Patches/fixes to build systems (such as GHC) are not documented properly.
E.g., here are all the GHC bindists where I had to backport the DESTDIR bugfix, because GHC developers don't curate their bindists: https://downloads.haskell.org/~ghcup/unofficial-bindists/ghc/curated/
Answering the above myself: ^ reading the source of config.yaml in ghcup-hs, it's clear that later entries would win. I.e, in the example above vanilla would take precedence over main. From config.yaml source:
It is definitely not recommended to enable both vanilla and non-vanilla channels. These are "main channels" so to speak and they are self-consistent (e.g. GHC and HLS versions are ABI compatible). Those invariants potentially go out the window if you mix them.
I advise against using the vanilla channel for regular users. These are not curated and experience has shown that upstream does not invest a lot of time in bindist quality.
Thank you for the detailed response.
It is definitely not recommended to enable both vanilla and non-vanilla channels. These are "main channels" so to speak and they are self-consistent (e.g. GHC and HLS versions are ABI compatible). Those invariants potentially go out the window if you mix them.
Ah! That is a valuable invariant. Thank you for pointing it out.
It might be helpful to explicitly note in the documentation the guarantees (or aspirational invariances, to be more accurate) that do or don't exist both within a channel, as well as across channels.
It might be helpful to explicitly note in the documentation the guarantees
https://hasufell.github.io/posts/2023-11-14-ghcup-is-not-an-installer.html