- cabal-devel - Haskell.org

cabal 3.8 pre-released!
by Mikolaj Konarski 03 Jun '22

03 Jun '22

Hello! The first 3.8 series cabal release candidate is available. Install via ghcup config add-release-channel \ https://raw.githubusercontent.com/haskell/ghcup-metadata/master/ghcup-prere…; ghcup install cabal 3.8.0.20220526 or manually from https://downloads.haskell.org/cabal/cabal-install-3.8.1.0-rc1/. We, the cabal team, are completely dependent on our invaluable contributors and collaborators, thanks to whom this pre-release is possible. Therefore, please test extensively and if anything critical is missing or broken that you'd like to see fixed in 3.8.1.0-final, let us know on the bug tracker. There is still a narrow window to change things and the cabal team will try to guide you along and help you implement them. The dynamic list of known grave bugs that could plausibly be solved for 3.8 is at https://github.com/haskell/cabal/issues?q=is%3Aopen+is%3Aissue+label%3A%22p… At the time of writing none of the bugs on the list is blocking the final 3.8 release. Changelogs are at https://github.com/haskell/cabal/blob/Cabal-v3.8.1.0-rc1/release-notes/Caba… https://github.com/haskell/cabal/blob/cabal-install-v3.8.1.0-rc1/release-no… The list of all authors of cabal is the git commit log. You are great. Happy hacking, Mikolaj

1 0

Minor user guide fixes
by Vilius Panevėžys 30 May '22

30 May '22

Please find attached a couple proposed fixes to the user guide.

3 7

Re: regression in ghc / cabal integration in 9.2.1
by Mikolaj Konarski 30 Oct '21

30 Oct '21

Hi George, Have you looked at the ticket I gave you? Here's one linked from it mentioning the topic of ghc-pkg compatibility with v2-install: https://github.com/haskell/cabal/issues/6508 I'm afraid we don't have any systematic exposition of cabal history with rationale for its major changes, but there's a changelog and the commit log. If you'd like to contribute something better, please do. Why the difference between GHC versions, I don't know, or whether upgrading your cabal would help (I doubt it). Regarding your workflow, perhaps ask around or look up in cabal tickets how other people do this now? I never run ghc directly, so I don't know. Best, Mikolaj On Sat, Oct 30, 2021 at 9:44 PM Brandon Allbery <allbery.b(a)gmail.com> wrote: > > Wasn't there specifically a new cabal version released to deal with > 9.2.1? 3.4.1.0 / 3.6.2.0? > > On Sat, Oct 30, 2021 at 3:24 PM George Colpitts > <george.colpitts(a)gmail.com> wrote: > > > > Thanks for the quick response Mikolaj. Sorry for the confusion, with cabal install I did use --lib but accidentally omitted that in my original email. In 9.0.1 this results in a successful compilation but in 9.2.1 it does not thus I believe this is a regression. > > > > Here's the output I got in 9.2.1: > > > > bash-3.2$ cabal install vector --lib > > Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.4.0.0 supports > > 'ghc' version < 9.1): /usr/local/bin/ghc is version 9.2.1 > > Warning: Unknown/unsupported 'ghc' version detected (Cabal 3.4.0.0 supports > > 'ghc' version < 9.1): /usr/local/bin/ghc is version 9.2.1 > > Resolving dependencies... > > Up to date > > bash-3.2$ ghc buggc.hs > > [1 of 1] Compiling Main ( buggc.hs, buggc.o ) > > > > > > buggc.hs:2:1: error: > > Could not find module ‘Data.Vector’ > > Perhaps you meant Data.Functor (from base-4.16.0.0) > > Use -v (or `:set -v` in ghci) to see a list of the files searched for. > > | > > 2 | import Data.Vector > > > > > > However I did figure out a workaround: cabal v1-install. > > > > As far as I can tell cabal (v2-) install breaks ghc-pkg and compilation. With cabal (v2-) install the workaround for ghc-pkg is to add the option "-f $HOME/.cabal/store/ghc-9.2.1/package.db" to the end of the command "ghc-pkg list". For compilation the workaround is to add "-package-db $HOME/.cabal/store/ghc-9.2.1/package.db" to the ghc-pkg. I don't understand why it was necessary for cabal v2-install to be incompatible with cabal v1-install. Is there a link to any documentation and justification for these incompatible changes? > > > > Thanks again, > > George > > > > > > > > On Sat, Oct 30, 2021 at 3:38 PM Mikolaj Konarski <mikolaj(a)well-typed.com> wrote: > >> > >> Hi George, > >> > >> Since many versions of cabal, `install` only installs executables, not > >> libraries, so if that worked for you, you must have had an old version > >> of cabal. > >> > >> Please see https://github.com/haskell/cabal/issues/6481 for some > >> context and to help you find a new workflow that works for you > >> (ideally, a standard one). > >> > >> Kind regards, > >> Mikolaj > >> > >> On Sat, Oct 30, 2021 at 5:40 PM George Colpitts > >> <george.colpitts(a)gmail.com> wrote: > >> > > >> > Thanks Ben! > >> > > >> > There seems to be a regression in ghc / cabal integration in 9.2.1. > >> > > >> > In 9.2.1 if I do > >> > > >> > cabal install vector > >> > > >> > Compilation of a file containing > >> > > >> > > >> > import Data.Vector > >> > > >> > > >> > main = undefined > >> > > >> > > >> > fails with > >> > > >> > Could not find module ‘Data.Vector’ > >> > Perhaps you meant Data.Functor (from base-4.16.0.0) > >> > Use -v (or `:set -v` in ghci) to see a list of the files searched for. > >> > | > >> > 2 | import Data.Vector > >> > | ^^^^^^^^^^^^^^^^^^ > >> > > >> > The preceding works on ghc 9.0.1 > >> > > >> > Should I file a bug against Cabal? > >> > > >> > Thanks > >> > George > >> > > >> > On Fri, Oct 29, 2021 at 12:54 PM Ben Gamari <ben(a)well-typed.com> wrote: > >> >> > >> >> Hi all, > >> >> > >> >> The GHC developers are very happy to at long last announce the > >> >> availability of GHC 9.2.1. Binary distributions, source distributions, > >> >> and documentation are available at > >> >> > >> >> https://downloads.haskell.org/ghc/9.2.1 > >> >> > >> >> GHC 9.2 brings a number of exciting features including: > >> >> > >> >> * A native code generation backend for AArch64, significantly speeding > >> >> compilation time on ARM platforms like the Apple M1. > >> >> > >> >> * Many changes in the area of records, including the new > >> >> `RecordDotSyntax` and `NoFieldSelectors` language extensions, as well > >> >> as Support for `DuplicateRecordFields` with `PatternSynonyms`. > >> >> > >> >> * Introduction of the new `GHC2021` language extension set, giving > >> >> users convenient access to a larger set of language extensions which > >> >> have been long considered stable. > >> >> > >> >> * Merging of `ghc-exactprint` into the GHC tree, providing > >> >> infrastructure for source-to-source program rewriting out-of-the-box. > >> >> > >> >> * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism > >> >> over levity of boxed objects (#17526) > >> >> > >> >> * Implementation of the `UnliftedDataTypes` extension, allowing users > >> >> to define types which do not admit lazy evaluation ([proposal]) > >> >> > >> >> * The new [`-hi` profiling] mechanism which provides significantly > >> >> improved insight into thunk leaks. > >> >> > >> >> * Support for the `ghc-debug` out-of-process heap inspection library > >> >> [ghc-debug] > >> >> > >> >> * Significant improvements in the bytecode interpreter, allowing more > >> >> programs to be efficently run in GHCi and Template Haskell splices. > >> >> > >> >> * Support for profiling of pinned objects with the cost-centre profiler > >> >> (#7275) > >> >> > >> >> * Faster compilation and a smaller memory footprint > >> >> > >> >> * Introduction of Haddock documentation support in TemplateHaskell (#5467) > >> >> > >> >> Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake > >> >> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous > >> >> contributors whose on-going financial and in-kind support has > >> >> facilitated GHC maintenance and release management over the years. > >> >> Moreover, this release would not have been possible without the hundreds > >> >> of open-source contributors whose work comprise this release. > >> >> > >> >> As always, do open a [ticket] if you see anything amiss. > >> >> > >> >> Happy testing, > >> >> > >> >> - Ben > >> >> > >> >> > >> >> [apple-m1]: https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html > >> >> [proposal]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-u… > >> >> [-hi profiling]: https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/ > >> >> [ghc-debug]: http://ghc.gitlab.haskell.org/ghc-debug/ > >> >> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new > >> >> _______________________________________________ > >> >> ghc-devs mailing list > >> >> ghc-devs(a)haskell.org > >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > >> > > >> > _______________________________________________ > >> > ghc-devs mailing list > >> > ghc-devs(a)haskell.org > >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > -- > brandon s allbery kf8nh > allbery.b(a)gmail.com

1 0

Re: regression in ghc / cabal integration in 9.2.1
by Mikolaj Konarski 30 Oct '21

30 Oct '21

Hi George, Since many versions of cabal, `install` only installs executables, not libraries, so if that worked for you, you must have had an old version of cabal. Please see https://github.com/haskell/cabal/issues/6481 for some context and to help you find a new workflow that works for you (ideally, a standard one). Kind regards, Mikolaj On Sat, Oct 30, 2021 at 5:40 PM George Colpitts <george.colpitts(a)gmail.com> wrote: > > Thanks Ben! > > There seems to be a regression in ghc / cabal integration in 9.2.1. > > In 9.2.1 if I do > > cabal install vector > > Compilation of a file containing > > > import Data.Vector > > > main = undefined > > > fails with > > Could not find module ‘Data.Vector’ > Perhaps you meant Data.Functor (from base-4.16.0.0) > Use -v (or `:set -v` in ghci) to see a list of the files searched for. > | > 2 | import Data.Vector > | ^^^^^^^^^^^^^^^^^^ > > The preceding works on ghc 9.0.1 > > Should I file a bug against Cabal? > > Thanks > George > > On Fri, Oct 29, 2021 at 12:54 PM Ben Gamari <ben(a)well-typed.com> wrote: >> >> Hi all, >> >> The GHC developers are very happy to at long last announce the >> availability of GHC 9.2.1. Binary distributions, source distributions, >> and documentation are available at >> >> https://downloads.haskell.org/ghc/9.2.1 >> >> GHC 9.2 brings a number of exciting features including: >> >> * A native code generation backend for AArch64, significantly speeding >> compilation time on ARM platforms like the Apple M1. >> >> * Many changes in the area of records, including the new >> `RecordDotSyntax` and `NoFieldSelectors` language extensions, as well >> as Support for `DuplicateRecordFields` with `PatternSynonyms`. >> >> * Introduction of the new `GHC2021` language extension set, giving >> users convenient access to a larger set of language extensions which >> have been long considered stable. >> >> * Merging of `ghc-exactprint` into the GHC tree, providing >> infrastructure for source-to-source program rewriting out-of-the-box. >> >> * Introduction of a `BoxedRep` `RuntimeRep`, allowing for polymorphism >> over levity of boxed objects (#17526) >> >> * Implementation of the `UnliftedDataTypes` extension, allowing users >> to define types which do not admit lazy evaluation ([proposal]) >> >> * The new [`-hi` profiling] mechanism which provides significantly >> improved insight into thunk leaks. >> >> * Support for the `ghc-debug` out-of-process heap inspection library >> [ghc-debug] >> >> * Significant improvements in the bytecode interpreter, allowing more >> programs to be efficently run in GHCi and Template Haskell splices. >> >> * Support for profiling of pinned objects with the cost-centre profiler >> (#7275) >> >> * Faster compilation and a smaller memory footprint >> >> * Introduction of Haddock documentation support in TemplateHaskell (#5467) >> >> Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake >> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous >> contributors whose on-going financial and in-kind support has >> facilitated GHC maintenance and release management over the years. >> Moreover, this release would not have been possible without the hundreds >> of open-source contributors whose work comprise this release. >> >> As always, do open a [ticket] if you see anything amiss. >> >> Happy testing, >> >> - Ben >> >> >> [apple-m1]: https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html >> [proposal]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-u… >> [-hi profiling]: https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/ >> [ghc-debug]: http://ghc.gitlab.haskell.org/ghc-debug/ >> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

[ANN] Cabal-3.4.1.0, cabal-install-3.4.1.0, Cabal-3.6.2.0, and cabal-install-3.6.2.0
by Emily Pillmore 08 Oct '21

08 Oct '21

Hello Haskell, The Cabal team is excited to announce the release of `Cabal-3.6.2.0`, and `cabal-install-3.6.2.0`. ## Changelog for `Cabal-3.6.2.0` and `cabal-install-3.6.2.0` This is the fifth release of the 3.0 release series for both packages. This minor version release introduces a set of fixes for some regressions seen when the tool interacts with `autoconf`, as well as some fixes for regressions to the way Paths_ modules interact with non-standard preludes: - Making Paths_ modules work with non-standard preludes again [#5962]( https://github.com/haskell/cabal/issues/5962 ) - Generate Paths_ module with qualified Data.List.last import so that compatibility with non-standard preludes is not regressed compared to cabal 3.4. - Windows: redo the fix to breakage caused by new autoconf; the wrong fix made cabal sometimes fail with old autoconf [#7494]( https://github.com/haskell/cabal/issues/7494 ) [#7649]( https://github.com/haskell/cabal/issues/7649 ) - Reverts #7510 that failed on Windows when used with pre-generated scripts included in packages such as network, time, process. - Adds a subtler fix/workaround for the deficiencies of new autoconf versions on Windows. **IMPORTANT NOTE**: The last bug affects configuration files generated with `autoconf-2.70` or later. They will not work with `cabal-3.4.0.0`. Please either upgrade to `3.4.1.0` or the new `3.6.2.0` releases. I'd like to thank the many contributors who offered patches, tickets, and other help in the preparation of this release. We appreciate all of your help! Happy hacking!

1 0

[ANN] Cabal-3.6.1.0 and cabal-install-3.6.0.0
by Emily Pillmore 09 Sep '21

09 Sep '21

Hello all, The Cabal team is excited to announce the release of both `Cabal-3.6.1.0`, and `cabal-install-3.6.0.0`! ## Changelog for `Cabal-3.6.1.0` This release of `Cabal` is a point release that allowed us to get some important features out into the ecosystem that just couldn't wait: - Include cmm-sources when linking shared objects - Prefer canonicalized path when guessing tools from GHC path - Fix `cabal test --enable-library-coverage` for modules in the `other-modules` field - set the PATH_SEPARATOR value to `;` when calling `./configure` on Windows (this is necessary for autoconf >=2.7) - Significant speedups to the solver ## Changelog for `cabal-install-3.6.0.0` This is the fourth release of the 3.0 release series for `cabal-install`, introducing features and quality of life improvements including: - Better support for `hsc2hs`, allowing users to pass additional options - Added an `--only-download` flag - extra-packages now works properly - `cabal init` UX improvements - GHC 9.2 support - Fixes to the backpack UX - Removing the spurious warnings for extraneous versions on internal packages - Alerts and spelling suggestions for mispelled comands - Massive improvements to code organization and repository health For a full set of release notes, see https://github.com/haskell/cabal/blob/master/release-notes/cabal-install-3.…. If you have issues, we'd love to hear about them here: https://github.com/haskell/cabal/issues. ## Plans for 3.8 The 3.6 release marks the first in a series where we work to modernize the Cabal project by means of doing away with the idiosyncratic and historical cruft built up, improving the contribution experience. Over the next 6 months, we'll be working hard to improve the state of the repository, including onboarding more maintainers and welcoming new contributors with clearer contribution requirements. To start, we've identified issues and new features that we aim to tackle for the 3.8 release spanning the following: - Better build info for tool creators - Support for stable package sets like LTS - Dropping build/test support for GHCs outside of the 5 year window - Finishing the multilib work - a byte-for-byte bidirectional parser - etc. You can find the full list of 3.8 project issues here: https://github.com/haskell/cabal/issues?q=is%3Aopen+is%3Aissue+project%3Aha…. I'd also like to thank the many contributors who offered patches, tickets, and other help in the preparation of this release. We appreciate all of your help! And a special thank you to the Haskell Language Server team for working with us and the Haskell Foundation to help fund work needed to improve the IDE. Happy hacking!

1 0

There are two sorts of auto-generated files
by Stefan Klinger 30 Aug '21

30 Aug '21

Hi, I, too, ran into the requirement to have a compiled Haskell binary print the Git hash it was derived from. There's a package for that (gitrev), which does not work to my satisfaction. Investigation led me to a wider concept. I now think that Cabal should discern two sorts of generated files: 1. Early generated files, that are not stored in the source repository but have to be present in a source distribution created by `cabal sdist`. 2. Late generated files, that are also not in the source distribution but are created during compilation. If that was possible, then the git hash problem would reduce to a special case of the first sort. (if it already is, where would I find it documented?) I've elaborated on this a bit, and provide my current attempt to include a git hash into a binary at https://github.com/s5k6/versionInfo which demonstrates the current issues when trying so implement such an approach using current Cabal. It also demonstrates the issue of the current auto-generated `Paths_…` module depending on the `base` package. What do you think? Cheers Stefan -- Stefan Klinger, Ph.D. -- computer scientist o/X http://stefan-klinger.de /\/ https://github.com/s5k6 \ I prefer receiving plain text messages, not exceeding 32kB.

3 5

Interleaving per-component hooks with build
by ÉRDI Gergő 06 Apr '21

06 Apr '21

Hi, I am looking for a way to do custom preprocessing for each component (of type `UnitId -> IO ()`) but this preprocessing depends on the dependencies of the component being already built. So imagine a Cabal file which defines a library and an exe, with the exe depending on the library. Then, I would need the following sequence of events to happen during `buildHook`: 1. myPreprocessing unitIdOfLibrary 2. standard build of library 3. myPreprocessing unitIdOfExe 4. standard build of exe How can I achieve that without copy-pasting large parts of the internals of `buildHook simpleUserHooks`? Thanks, Gergo

1 3

plan.json documentation
by Nicolas Frisby 19 Mar '21

19 Mar '21

Hi all. Without show-build-info yet and without a cabal-install library, a hobby project relies on parsing plan.json to access eg the list of .cabal files and their flags as configured during the most recent cabal-install invocation. I haven't found much documentation about plan.json. I'm particularly curious what are its current semantics and intended use, and if these are intended to remain stable going forward. Some example specific questions: * Would show-build-info supplant plan.json? If so, would there be a deprecation delay? * The docs say "A JSON serialization of the computed install plan intended for integrating cabal with external tooling." It seems likely that answering my questions will involve explaining what an "install plan" is. (I'm unfortunately unfamiliar with Cabal internals, and ReadTheDocs search doesn't seem to support phrases as queries.) * What determines which packages have entries in the plan.json file after a particular cabal-install invocation? Will it always include all local .cabal files? (🤞) * Is there enough information in the plan.json file in order to map an entry there for source repository package to the corresponding path under the builddir's `src` directory? There seems to be some sort of hash involved in that path and I haven't figured what its inputs are and whether the plan.json file includes them all. Thank you for your time. -Nick PS - My hobby project driving this question is based on wanting to parse all local source files without having to typecheck/build any of them (ideally nor their non-local dependencies). I need each source file path and corresponding language extensions etc in order to invoke the parser. (hie-bios doesn't suffice because its solution to this problem involves building dependencies, possibly including local packages.) If you see a more direct path that doesn't involve plan.json, please say so. Thanks again!

2 1

[RFC] Qualified module renamings
by Edward Z Yang 01 Mar '21

01 Mar '21

Today, using the 'mixins' field you can rename modules that come from other packages by manually expressing a renaming one-by-one. In some Backpack use cases, you may have a lot of modules that you would like to mechanically rename into some subnamespace; today, you have manually list each renaming one by one. https://github.com/haskell/cabal/pull/7303 contains an implementation of one possible way to extend mixin syntax to support qualified renaming; the implementation is very simple. The syntax here is based off of Richard Eisenberg's local modules proposal (https://github.com/ghc-proposals/ghc-proposals/pull/283) which supports the qualified keyword before module exports/imports which has the same effect (bring the module into scope under a sub-module namespace). However, the PR isn't really meant to be an end all to the discussion: it's just to show that it's pretty simple to implement this functionality. There are two primary axes which I am looking for feedback: * Expressivity. The current PoC implementation only permits unconditionally prefix-ing all modules that would have been brought into scope by the mixin; e.g., transforming module A to Prefix.A. Edward Kmett has expressed that in some cases, he would like it if you could implement the import as a suffix. One could also imagine allowing arbitrary string transformations. Opinions on where to draw the line for expressivity are solicited. * Syntax. The current syntax is "pkgname qualified Prefix" as it is symmetric with "pkgname hiding (A, B)" and it was simple to implement. But I am not particularly attached to this syntax, and am open to other suggestions. If we permit suffixing, a wildcard based syntax like "pkgname (* as *.Suffix)" may be preferable (though modestly more complex to specify and implement; for example, is the glob recursive over dots?). Edward Kmett has offered some other possibilities at https://github.com/haskell/cabal/issues/7290#issue-812744575? Thanks Oleg for reminding me to send this RFC to this mailing list. Cheers, Edward

4 8