Cabal 3.10 last call for contributions

Mikolaj · November 17, 2022, 2:41pm

Hi! Would you like cabal 3.10 to have your favourite bugfix, feature or overall spiffiness? If so, please let us help you help yourself. We are going to soft-freeze cabal 3.10 in a month or two and ship a little later, around the GHC 9.6 release date. There is still time to fix your favourite regression

https://github.com/haskell/cabal/issues?q=is%3Aopen+label%3A%22regression+in+3.8%22%2C%22type%3A+regression%22+

or add your high priority feature (or argue for bumping the priority of an existing ticket)

https://github.com/haskell/cabal/labels/priority%3A%20high%20%3Afire%3A

The friendly team of cabal maintainers is at your disposal whether you need a PR review, a design discussion in a ticket, or you just get stuck or urgently need somebody to chat to (the #hackage IRC/matrix room is open).

Cabal 3.10 is going to be mostly a bugfix release, so there may or may not be a release candidate for you to try to break. However, brave people are continuously dogfooding the master branch from github artifacts (at the bottom of ‘validate’ CI jobs) or gitlab pipelines (more flavours, including statically linked Alpine Linux)

Another way you can contribute is by picking up a newcomer-labelled ticket. Yet another is triaging new tickets, e.g., via

https://www.codetriage.com/haskell/cabal

Don’t worry if you feel you’d need to learn a lot — cabal is a large and constantly changing system, so most of us are forgetting faster than learning. However, purity, types and tests often permit to focus, code-dive and fix or improve a hot subsystem in relative isolation.

See you there,
Mikolaj

Edited: Fixed the first link that discourse mangled.

Mikolaj · December 1, 2022, 1:11pm

Two examples of short (in terms of LOC) newcomer cabal tickets that are particularly tasty, important for users and not mindless at all:

github.com/haskell/cabal

Dependency resolution errors due to non-upgradeable packages should refer to compiler version

opened 02:03PM - 18 Feb 22 UTC

sjakobi

type: enhancement cabal-install: solver attention: pr-welcome newcomer: 1-one-line-change newcomer re: error-message

This issue is inspired by two stackoverflow questions where the user wasn't sure… how to resolve dependency problems involving `base` and `template-haskell`: https://stackoverflow.com/questions/71173561/how-to-resolve-dependency-issues-in-cabal-project: ``` $ cabal v2-build Resolving dependencies... cabal.exe: Could not resolve dependencies: [__0] trying: TMS-0.1.0.0 (user goal) [__1] trying: persistent-2.13.3.0 (dependency of TMS) [__2] next goal: template-haskell (dependency of persistent) [__2] rejecting: template-haskell-2.18.0.0/installed-2.18.0.0 (conflict: persistent => template-haskell>=2.13 && <2.18) [__2] skipping: template-haskell-2.18.0.0 (has the same characteristics that caused the previous version to fail: excluded by constraint '>=2.13 && <2.18' from 'persistent') [__2] rejecting: template-haskell-2.17.0.0, template-haskell-2.16.0.0, template-haskell-2.15.0.0, template-haskell-2.14.0.0, template-haskell-2.13.0.0, template-haskell-2.12.0.0, template-haskell-2.11.1.0, template-haskell-2.11.0.0, template-haskell-2.10.0.0, template-haskell-2.9.0.0, template-haskell-2.8.0.0, template-haskell-2.7.0.0, template-haskell-2.6.0.0, template-haskell-2.5.0.0, template-haskell-2.4.0.1, template-haskell-2.4.0.0, template-haskell-2.3.0.1, template-haskell-2.3.0.0, template-haskell-2.2.0.0 (constraint from non-upgradeable package requires installed instance) [__2] fail (backjumping, conflict set: persistent, template-haskell) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: persistent, TMS, template-haskell ``` https://stackoverflow.com/questions/71092123/installing-a-haskell-program-like-hackage-cli: ``` $ cabal v2-build Resolving dependencies... cabal: Could not resolve dependencies: [__0] trying: hackage-cli-0.1.0.0 (user goal) [__1] next goal: base (dependency of hackage-cli) [__1] rejecting: base-4.15.1.0/installed-4.15.1.0 (conflict: hackage-cli => base>=4.10.0.0 && <4.13) [__1] skipping: base-4.16.0.0, base-4.15.1.0, base-4.15.0.0, base-4.14.3.0, base-4.14.2.0, base-4.14.1.0, base-4.14.0.0, base-4.13.0.0 (has the same characteristics that caused the previous version to fail: excluded by constraint '>=4.10.0.0 && <4.13' from 'hackage-cli') [__1] rejecting: base-4.12.0.0, base-4.11.1.0, base-4.11.0.0, base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, base-4.9.0.0, base-4.8.2.0, base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1, base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0, base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2, base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2, base-3.0.3.1 (constraint from non-upgradeable package requires installed instance) [__1] fail (backjumping, conflict set: base, hackage-cli) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: base, hackage-cli ``` It would helpful if such messages would make the connection to the compiler version being used and indicate that the problem can be resolved by picking a different version.

github.com/haskell/cabal

Try to combine lists of non-installable and non-upgradable packages

opened 11:22PM - 09 Nov 22 UTC

grayjay

cabal-install: solver type: refactor newcomer: 3-multi-file-refactor newcomer

Issue #8489 showed that cabal contains two separate lists of packages that canno…t be installed. This issue is for determining whether the lists have the same meaning and combining them if they are redundant. #8501 synced the contents of the two lists. One is in the solver and is described as non-installable: https://github.com/haskell/cabal/blob/09c90de378273ae2f08fb605ea03e857ec2b8720/cabal-install-solver/src/Distribution/Solver/Modular/Solver.hs#L158-L173 The other is in Distribution.Client.Dependency and is described as non-upgradable: https://github.com/haskell/cabal/blob/09c90de378273ae2f08fb605ea03e857ec2b8720/cabal-install/src/Distribution/Client/Dependency.hs#L387-L414 If only one is needed, I think we should keep the one in Distribution.Client.Dependency, since it is better to make the solver more general and pass in constraints rather than hard code package names.

Mikolaj · December 28, 2022, 4:40pm

BTW, if somebody could review any of the pending cabal PRs, that would help immensely:

https://github.com/haskell/cabal/pulls?q=is%3Aopen+is%3Apr+label%3A%22attention%3A+needs-review%22

If you only have rights to write a comment in the PR, don’t worry, ping me in the comment and either wait until I grant you full review permissions or just review informally in the comment and I will take care of the formalities with merge conditions.

Mikolaj · January 27, 2023, 2:59pm

And here we go! The unofficial prerelease of cabal 3.10 is out. Please install it, use it and report problems at our issue tracker at Issues · haskell/cabal · GitHub

The prerelease is called cabal 3.9.0.0 and you can get it via ghcup as follows:

ghcup config add-release-channel https://raw.githubusercontent.com/haskell/ghcup-metadata/master/ghcup-prereleases-0.0.7.yaml
ghcup tui

Then enable “Show all versions” and then install and set “cabal 3.9.0.0”. Alternatively, the binaries for the same four platforms are at

https://downloads.haskell.org/~cabal/cabal-install-3.9.0.0/

Let’s do it together!

Mikolaj · January 27, 2023, 3:24pm

Oh, and the unofficial changelog of this unofficial prerelease is this directory:

If you stumble on a change that is not sufficiently summarized there, e.g, some backwards compat workaround hints are missing, please report that, too.

taylorfausak · January 28, 2023, 1:49pm

This looks like an exciting release! Unfortunately I wasn’t able to try it out since I’m using Linux on ARM64. But these change log items caught my eye:

#8162: New haddock-project command for easily building documentation of all local packages. And using --hackage to link to Hackage documentation for dependencies.
#8534: New auto-generated PackageInfo_* module that includes the package name, version number, synopsis, copyright, and homepage. I’ve often wondered why more fields from the package description aren’t included in the Paths_* module, and this adds some of them!
#8261: New --prefer-oldest flag for picking a build plan with the oldest versions of dependencies. This should be useful for ensuring that dependency bounds are accurate.
#7386: Use XDG directories, like $XDG_STATE_HOME/cabal rather than ~/.cabal/store.

Mikolaj · January 28, 2023, 2:56pm

Right, that’s pretty exciting stuff and there is more.

Re arm64, regrettably we don’t have a permanent maintainer for our github and gitlab CI/release setups and we barely strive to keep any builds running, so Linux on arm64 just dropped off at some point. Let me see if I can get a one-time help with this particular problem…

coot · January 30, 2023, 8:58am

For #8162 we need to wait for ghc release which will contain all the necessary changes that were made to haddock.

mpickering · January 30, 2023, 11:17am

I am very late here but I wonder if a better interface for haddock-project is to instead switch into “project” mode when there are multiple targets to generate documentation for when using cabal haddock?

Anyway to answer this question is when does one use cabal haddock and when does one use cabal haddock-project? There also seems to be a --hackage option for cabal haddock-project which is different to --haddock-for-hackage?

It seems that by default the haddock-project should place it’s output in dist folder (like all the other commands).

The haddock-project should also allow you to specify cabal targets (as well as respect whether you have configured with tests:enable, bench:enable). The documentation says it builds for “all” local components.

After all we don’t have build-project or test-project, the interface for this command seems quite strange.

Mikolaj · January 30, 2023, 11:41am

Please note that cabal/haddock support for multiple libraries/packages is a long neglected feature that we don’t attempt to suddenly get right on the first attempt, but iterate on. Users, at long last, have the ability to do anything in a (semi-)automated way with haddocks of their multi projects and we do expect plenty of feedback. Thank you also for yours, @mpickering. Did I get the story right, @coot? I wonder if we should open a ticket or designate an existing one to gether feedback on #8162 and related ones in one place. Did the last one get closed?