Cabal 3.2 has finally been released, including new bug fixes, features, and a Hackage Server update. You can find the project Changelog on github if you want the rest of the changeset between this version and Cabal 3.0.
In this post, we'll go over some of the highlights in this release, as well as detail some upcomings line items and milestones for future planned work on the library.
The 3.2 changeset features the following:
- Improved benchmarking support
- Solver optimizations
- Better
.lhssupport - Local no-index repositories
--benchmark-option(s)is now supported by thev2-*commands as of #6224
Of the changes we see in Cabal 3.2, you'll notice from the changelog that several previous bugs have been fixed, and some new features have been added. In this version, bench now accepts the --benchmark-option(s) flag so that you can now pass options to benchmark executables in the same sense that --test-option(s) works. For example, if you're running criterion as I do for many projects, you often want to disiplay output, and one would have to call something similar to cabal run bench -- --arg1 --arg2 ... in order to get it to run with that option. Now, I can simply pass the --benchmark-option(s) argument and use cabal bench. That's a quality of life improvement! The same support for --benchmark-option(s) is now available for all of the v2-* era commands.
Solver optimized skip for a package version if it doesn't resolve conflicts in the last version controlled by
--fine-grained-conflicts(on by default) as of #5918
Some new optimizations have been added to Cabal to improve the solver's ability to skip packages that it know will not fix conflicts. The --fine-grained-conflicts flag is now used by default under the hood, and flag triggers the solver to not consider other versions of a package that have no hope of solving a conflict if the last tried version didn't solve it. For a really detailed description of how this works, including examples, see /u/grayjay's post on the pull request.
.lhsfiles now works withcabal v2-runas of #6134
The run command now supports a lite version of Literate Haskell, without additional syntax. Not much to say here. Literate Haskell fans rejoice.
Local, no-index repositories with related syntax are available as of #6448
Thanks to the hard work of Oleg Grenrus, it is now possible to use a directory of .tar.gz package files as a local package repository using a really concise syntax:
repository my-local-repository
url: file+noindex:///absolute/path/to/directoryThe index will be constructed automatically and cached in the given directory by Cabal from the <package-name>-<version>.tar.gz files in the directory, and will use optional corresponding <package-name>-<version>.cabal files as revised package description. This allows to easily test source-distributions locally before uploading to Hackage, or also create self-contained source-distros including all dependencies that don't require any internet connectivity to build!
Ever since GHC 8.8.1 was released, the Hackage server code-base has been undergoing some pretty thorough upgrades, which has significantly delayed the upload of Haddock documentation for special packages such as base for GHC version 8.8 and 8.10 which required Cabal 3.0 support.
Last weekend we were finally ready to go and Hackage with Cabal 3.0 support went live (on May 3rd, Sunday evening shortly past 19:30 UTC to be more precise), at last! Subsequently, the previously held-back GHC boot package releases were pushed and by now almost all (except for a couple ones which need extra work -- we're on it, there's no need to file tickets about it!) have been succesfully uploaded onto Hackage.
Hackage server has gone through an extensive upgrade in order to accommodate the API-breaking Cabal 3.0 release and as can be seen on e.g. hackage-server#852 and hackage-server#862 various people have stepped up and helped push along the migration by writing patches or reviewing code. In other words, updating Hackage to Cabal 3 has been made possible by a group effort!
The result of this upgrade means that you can now specify cabal-version: 3.0 in your package description (NB: cabal-version: 3.2 does not exist as there were no new specification features in Cabal 3.2). For more details about the new features in this new cabal specification version, see Cabal's Specification Changelog. The minimum required cabal-version:-value for new releases has been bumped to version 1.10 to reduce the risk of less tested corner-cases in these ancient specification versions to cause problems, and as well as the fact that it's practically unfeasible to use cabal clients prior to version 1.10 with Hackage nowadays.
Unfortunately, we don't yet allow uploading packages making use of Cabal 3.0's highly anticipated new feature (besides switching over to Nix-style local-builds by default) of supporting multiple public libraries in a single Cabal package because there's still non-negligible issues that need resolving in both Hackage and Cabal. We need your help getting this feature ready for prime time!
Some less notable, but nice-to-have changes are:
- Upgraded to UTC-based ISO-8601 datatime formats (conveniently matches format for
cabal's--index-state-pinning flag) across the board. - The SHA256 hashes of
.cabalrevisions are now shown in the revision tables, along with changes to the layout of the table itself to make better use of the screen estate (see e.g. http://hackage.haskell.org/package/HsYAML-0.2.1.0/revisions/) - Internal libraries are now shown properly in the depedency details view (e.g. see http://hackage.haskell.org/package/haddock-library-1.5.0.1/dependencies ), where previously, you wouldn't have seen the internally vendored
attoparseccomponent. Moreover, the dependencies of internal sublibs are now properly accounted in the dependency summary on the package page. - Fixes to the way CRLF are handled mean your READMEs now render less wonkily (addresses jgm/cheapskate#25).
Hackage server is critical infrastructure for all of Haskell, and we need to make sure that it sufficient support going forward to ensure extraordinary delays like the Cabal 3.0 upgrade do not have to happen again. And now the next big thing around the corner is unlocking public multi-libs! So, in order to address this, we are putting out a call for contributors. In the past, it may not have been clear that this infrastructure is entirely free and open source software, and anyone can contribute their help at any time -- there's more than enough tasks available for everyone! As of this announcement, we want to state clearly that we are happy to mentor and ramp up any contributors who want to make an impact on critical infra, and we definitely need the help! If you want to contribute, please join the #hackage Freenode server and get in touch with sclv, phadej, hvr, or davean. They'd be happy to help.
Let's switch back to Cabal proper and talk about future plans and directions for Cabal, and how contributors can help with the project.
Now that the v2-* suite of commands has been successfully implemented and tested with the help of the Haskell community's feedback, it's time to start thinking about migrating the codebase away v1-*, since it constitutes a majority of dead weight in the codebase. The warnings that we all started seeing in Cabal 2.4 were a strategy to raise awareness of this end, which was the goal all along: a full migration to the v2 suite of commands. In fact, if you've been using the same Cabal commands without prefixing v1 or v2, as of Cabal 3.0, you've already been using the v2 commands! There were very few hurdles to migrating between the two, and for most, it was a drop-in replacement.
The v1 legacy code represents a significant burden to the existing maintainership, as well as to new contributers who have to navigate lots of pointy edges in that are unclear in their meaning and possibly useless in their existence. In order to keep Cabal flexible, we're going to start the process of excising the legacy code. Talk to the maintainers if you want to help with this. I'm sure this will be a cathartic process for us all.
As already mentioned in the Hackage related section, one of the next big things for Hackage and Cabal everyone's many people have been waiting for is support for public multi-lib packages. Since Cabal 3.0 this is available as experimental feature and you can use it locally but it is not considered ready for distribution via Hackage yet. But you can help make it ready sooner than later. You can check the status of the feature on the checklist, or by asking in the #hackage Freenode channel.
Cabal tends to release with each GHC version, which means the next release will be with GHC 8.12 at the end of the year (December or January). The milestones for this release are located in the issues list, and will feature some of the mentioned excision of old legacy code (e.g. removing old sandbox functionality, renaming dist-newstyle), as well as introducing some new features (e.g. better path abstraction, public multi-libs improvements, etc).