haskell
Cabal-hooks release missing from Hackage
Cabal-3.14.0.0 introduced support for build-type: Hooks using the Cabal-hooks package, but it appears the Cabal-hooks package itself has not yet been uploaded to Hackage. Please can this be published? Perhaps this step needs to be added to the release checklist?
https://hackage.haskell.org/package/Cabal-hooks
I suppose it's up to the release manager after it's been added to the release checklist at https://github.com/haskell/cabal/wiki/Making-a-release, so we'd need help from @sheaf or anybody that can confirm this package needs to be released and how exactly (also at point releases? anything to be updated in that package whenever releasing? etc.).
I have updated the release checklist to include the Cabal-hooks library. As this package is versioned separately from the Cabal library, it will only need to be released on Hackage when its version number changes (following the PVP).
As Cabal 3.14 is the first version supporting build-type: Hooks, we do need a corresponding release of Cabal-hooks on Hackage. Perhaps @Kleidukos, as the release manager for Cabal 3.14, could upload Cabal-hooks to Hackage? The main purpose of the package is to provide documentation for the Hooks API, with a curated set of re-exports of the relevant portions of the Cabal library.
As this package is versioned separately from the Cabal library, it will only need to be released on Hackage when its version number changes (following the PVP).
The main purpose of the package is to provide documentation for the Hooks API, with a curated set of re-exports of the relevant portions of the Cabal library.
Due to the re-exports, the independent versioning may be trickier than hoped. I wonder if we should set up some kind of automated check for whether the re-exported API has changed since the last release of Cabal, the library. Even if it's a long shot, several things needs attention, I think.
-
validate.ymlcurrently doesn't mentionCabal-hooks. Should we check regularly thatCabal-hooksbuilds? Maybe a separate workflow that is triggered only whenCabal{,-syntax,-hooks}-paths are touched? -
Should dependency bounds in
Cabal-hooks.cabalbe tightly coupled with the versions ofCabal(-syntax)? They have been so far (e.g. https://github.com/haskell/cabal/commit/88737ef712507e7b70a7df63b075dd19f1ebaaa3#diff-5b143890f5b4458c6494dd5507dfed87b9f08af46368bc9f22281416b3130984) but I am not sure they should be.
As this package is versioned separately from the Cabal library, it will only need to be released on Hackage when its version number changes (following the PVP).
The main purpose of the package is to provide documentation for the Hooks API, with a curated set of re-exports of the relevant portions of the Cabal library.
Due to the re-exports, the independent versioning may be trickier than hoped. I wonder if we should set up some kind of automated check for whether the re-exported API has changed since the last release of Cabal, the library.
Indeed. The original RFC for build-type: Hooks says that we should expect the versions of the Cabal library and Cabal-hooks to be tightly coupled (NB: this should answer (2)) due to these re-exports, at least until we manage to further extricate the two libraries. Given that, it seems the ideal course of action (to me) would be to use @geekosaur's API-checking functionality to detect when a version bump is necessary. However, given that we re-export LocalBuildInfo, it seems almost certain we will at least need a new major Cabal-hooks version for each new major Cabal library version.
Unless anybody objects, let me propose to version Cabal-hooks the same as Cabal the library. For the 3.14 release, that would be, exceptionally, 3.14.0.0. A PR that bumps the version to 3.14.0.0 is very welcome. For 3.16 onwards, it's probably going to be 3.16.1.0, etc.
What I understand from the discussion is that the simplest process is to release Cabal-hooks together with any major version of Cabal the library, keeping the bounds tightly coupled (that's my answer to the @ulysses4ever 's point 2 above). Later on, when/if the API-checking tools is fully deployed and/or Cabal-hooks is less entangled with Cabal the library, we may try to release less often, at the cost managing/revising bounds, etc. It's not clear if that's worthwhile, but we will have a better idea once we release a couple of versions using the dumb process. If there are no objections, let's add this to the release checklist, copy-pasting relevant points concerning Cabal the library.
Regarding exteding the CI (point 1 by @ulysses4ever above), that's a great idea, though I'd also start with something dumb --- just add Cabal-hooks cheaply in there and see what happens. Volunteers?
Once the version-bumping PR is merged, let's upload to Hackage. Anything blocking this? Anything else to consider? Objections?