search

haskell / cabal

Official upstream development repository for Cabal and cabal-install
https://haskell.org/cabal
Other
1.63k stars 696 forks source link

Cabal-hooks release missing from Hackage #10412

Open adamgundry opened 1 month ago

adamgundry commented 1 month ago

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 commented 1 month ago

@sheaf?

geekosaur commented 1 month ago

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

Mikolaj commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

Thanks for the reminder!

ulysses4ever commented 1 month ago

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. https://github.com/haskell/cabal/commit/88737ef712507e7b70a7df63b075dd19f1ebaaa3#diff-5b143890f5b4458c6494dd5507dfed87b9f08af46368bc9f22281416b3130984) but I am not sure they should be.

sheaf commented 1 month ago

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.

Mikolaj commented 4 weeks ago

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?