Cabal-hooks release missing from Hackage

[adamgundry]

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

[ulysses4ever]

@sheaf?

[geekosaur]

Is that up to him? It lives in our repo.

[Mikolaj]

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.).

[sheaf]

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.

[Kleidukos]

Thanks for the reminder!

[ulysses4ever]

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.

1. validate.yml currently doesn't mention Cabal-hooks. Should we check regularly that Cabal-hooks builds? Maybe a separate workflow that is triggered only when Cabal{,-syntax,-hooks}-paths are touched?

2. Should dependency bounds in Cabal-hooks.cabal be tightly coupled with the versions of Cabal(-syntax)? They have been so far (e.g. 88737ef#diff-5b143890f5b4458c6494dd5507dfed87b9f08af46368bc9f22281416b3130984) but I am not sure they should be.

[sheaf]

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.