- cabal-devel - Haskell.org

[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

cabal-install-3.4.0.0-rc4 and Cabal-3.4.0.0-rc4 are now available
by Oleg Grenrus 12 Oct '20

12 Oct '20

The Cabal developers are happy to announce the fourth (and hopefully final) release candidate for cabal-install-3.4.0.0 The corresponding tags are `cabal-install-3.4.0.0-rc4` and `Cabal-3.4.0.0-rc4` https://github.com/haskell/cabal/releases/tag/cabal-install-3.4.0.0-rc4 https://github.com/haskell/cabal/releases/tag/Cabal-3.4.0.0-rc4 and there is a handful of binaries available at https://oleg.fi/cabal-install-3.4.0.0-rc4/ Ubuntu-16.04 bindist should work on most recent Linux distributions, (requires at least kernel 3.15, compiled against glibc-2.23). Similarly darwin-sierra bindist should work on newer macOSes as well. The binary distributions are built from the source distributions of Cabal and cabal-install available at the same directory. Additionally I have uploaded candidates to Hackage: https://hackage.haskell.org/package/Cabal-3.4.0.0/candidate https://hackage.haskell.org/package/cabal-install-3.4.0.0/candidate --- NOTE: If you are testing the recently announced GHC-9.0.1-alpha1 [1], it is highly recommended that you use cabal-install-3.4.0.0. [1]: https://mail.haskell.org/pipermail/ghc-devs/2020-September/019286.html --- Please comment on a plan for gradual removal of v1-commands. https://mail.haskell.org/pipermail/cabal-devel/2020-September/010488.html There have been few replies on reddit [2] but no replies on the mailing list. [2]: https://www.reddit.com/r/haskell/comments/j0ruyx/rfc_a_plan_to_gradual_remo… --- Since the third release candidate (rc3) following issues were resolved: - Pass -optcxx for GHC >= 8.10 https://github.com/haskell/cabal/issues/6421 https://github.com/haskell/cabal/pull/7072 - Require custom-setup for cabal-version: 1.24 and later https://github.com/haskell/cabal/issues/7091 - Allow Win32-2.10.0.0 https://github.com/haskell/cabal/pull/7085 - Remove v2-build beta note from --help https://github.com/haskell/cabal/issues/7090 - Fix command notes being replaced by descriptions https://github.com/haskell/cabal/pull/7089 - documentation: Nix style local builds have become the default https://github.com/haskell/cabal/pull/7097 - Provide slightly more information when there are multiple occurences of same package https://github.com/haskell/cabal/pull/7078 Since the second release candidate (rc2) following issues were resolved: - Regression in cabal repl handling of `-z` flag https://github.com/haskell/cabal/issues/7039 - Allow Win32-2.9.0.0 https://github.com/haskell/cabal/issues/7040 - v2-update updates file+noindex repositories cach https://github.com/haskell/cabal/issues/7061 - Fix cabal sdist issues for packages with data-files https://github.com/haskell/cabal/issues/7028 Since the first release candidate (rc1) following issues were resolved: - Bump process version required for job support to 1.6.9 https://github.com/haskell/cabal/issues/6986 - GHC-8.12 is GHC-9.0 https://github.com/haskell/cabal/issues/7019 - cabal-install-head v2-install fails to process source-repository-package https://github.com/haskell/cabal/issues/7007 cabal-install-3.4 release highlights are: - Support for upcoming GHC-9.0 - Removal of sandboxes - Improved public sublibrary support - `active-repositories` configuration - Various `cabal init` improvements - Various `cabal sdist` improvements - `source-repository-package` are not treated as local packages - Added `list-bin` command Complete release notes (drafts) are at: https://github.com/haskell/cabal/tree/master/release-notes Please do test this release and let us know if you encounter any issues: https://github.com/haskell/cabal/issues - Oleg

1 0

RFC: A plan to gradual removal of v1- commands
by Oleg Grenrus 27 Sep '20

27 Sep '20

Dear development aware cabal users I request you to comment on a plan to gradually remove `v1-` commands. Some users have commented about the notice in `v1-` commands' `--help`: It is a legacy feature and will be removed in a future release of cabal-install. Please file a bug if you cannot replicate a working v1- use case with the nix-style commands. This note is vague, and indeed we don't have any concrete plan *when* something will be removed. Lets have one. At the moment, in upcoming `cabal-install-3.4.0.0` we have following commands: v1-build Compile all/specific components. v1-configure Prepare to build the package. v1-repl Open an interpreter session for the given component. v1-run Builds and runs an executable. v1-test Run all/specific tests in the test suite. v1-bench Run all/specific benchmarks. v1-freeze Freeze dependencies. v1-haddock Generate Haddock HTML documentation. v1-exec Give a command access to the sandbox package repository. v1-update Updates list of known packages. v1-install Install packages. v1-clean Clean up after a build. v1-doctest Run doctest tests. v1-copy Copy the files of all/specific components to install locations. v1-register Register this package with the compiler. v1-reconfigure Reconfigure the package if necessary. I propose the following plan: In 3.4.0.0 (to be officially released in a week from GHC-9.0.1 release, i.e. soon) we have already removed `v1-sdist`, as `v2-sdist` have completely subsumed the functionality, yet the interface is slightly different. In 3.6.0.0 (to be release around GHC-9.2) we will remove - v1-update: the v2-update should already completely subsume the functionality (but this have to be checked) - v1-doctest: is a commeand which never worked properly - v1-exec: its description mentions sandbox package repository, as sandbox are already removed, v1-exec has no use In 3.8.0.0 we will remove what I'd call "interactive" development commands: - v1-freeze - v1-bench - v1-reconfigure - v1-repl - v1-run - v1-clean These are commands which I don't expect to be heavily used in scripts. That would leave us with what I consider essential commands. I think these are sufficient if `v1-` commands are used in some bigger build process. (Though, I'd suggest to use raw `./Setup`) This can be removed in 3.10 (or more conservatively in 3.12). - v1-build - v1-configure - v1-haddock - v1-test - v1-install - v1-copy - v1-register These commands will be removed in 3.12 (skipping the 3.10). In summary: v1-sdist now 3.4 v1-build two years 3.12 v1-configure two years 3.12 v1-repl one year 3.8 v1-run one year 3.8 v1-test two years 3.12 v1-bench one year 3.8 v1-freeze one year 3.8 v1-haddock two years 3.12 v1-exec 6 months 3.6 v1-update 6 months 3.6 v1-install two years 3.12 v1-clean one year 3.8 v1-doctest 6 months 3.6 v1-copy two years 3.12 v1-register two years 3.12 v1-reconfigure one year 3.8 I should mention that we don't test any of `v1-` commands anymore. The code is there, and if it works it is good, but if it doesn't, we wont actively pursue fixing it (rather concentrating on whatever issues are holding you from migration to v1-build). I would value comments whether the list for 3.6 (v1-update, v1-doctest, v1-exec) is found controversial. Very rough estimate is that 3.6 will be released early 2021, in about a half a year from now. 3.8 would happen a year from now. (Fall 2021) 3.12 where the v1-build is gone would happen in two years from now. (Fall 2022) Disclaimers: I don't want to set the plan in stone. In other words, "All rights reserved", but we would avoid removing anything earlier than agreed. Yet, it's impossible to predict the future, and we might be forced to diverge from that plan. The version numbers are informative, 3.10 could be 4.0, or the release schedule could be accelarated or slowed down. We will stick to the time based definitions. - Oleg

1 1

cabal-install-3.4.0.0-rc3 and Cabal-3.4.0.0-rc3 are now available
by Oleg Grenrus 14 Sep '20

14 Sep '20

The Cabal developers are happy to announce the third release candidate for cabal-install-3.4.0.0 The corresponding tag are `cabal-install-3.4.0.0-rc3` and `Cabal-3.4.0.0-rc3` https://github.com/haskell/cabal/releases/tag/cabal-install-3.4.0.0-rc3 https://github.com/haskell/cabal/releases/tag/Cabal-3.4.0.0-rc3 and there is a handful of binaries available at https://oleg.fi/cabal-install-3.4.0.0-rc3/ Ubuntu-16.04 bindist should work on most recent Linux distributions, (requires at least kernel 3.15, compiled against glibc-2.23). Similarly darwin-sierra bindist should work on newer macOSes as well. Since the second release candidate (rc2) following issues were resolved: - Regression in cabal repl handling of `-z` flag https://github.com/haskell/cabal/issues/7039 - Allow Win32-2.9.0.0 https://github.com/haskell/cabal/issues/7040 - v2-update updates file+noindex repositories cach https://github.com/haskell/cabal/issues/7061 - Fix cabal sdist issues for packages with data-files https://github.com/haskell/cabal/issues/7028 Since the first release candidate (rc1) following issues were resolved: - Bump process version required for job support to 1.6.9 https://github.com/haskell/cabal/issues/6986 - GHC-8.12 is GHC-9.0 https://github.com/haskell/cabal/issues/7019 - cabal-install-head v2-install fails to process source-repository-package https://github.com/haskell/cabal/issues/7007 cabal-install-3.4 release highlights are: - Support for upcoming GHC-9.0 - Removal of sandboxes - Improved public sublibrary support - `active-repositories` configuration - Various `cabal init` improvements - Various `cabal sdist` improvements - `source-repository-package` are not treated as local packages - Added `list-bin` command Complete release notes (drafts) are at: https://github.com/haskell/cabal/tree/master/release-notes Please do test this release and let us know if you encounter any issues: https://github.com/haskell/cabal/issues - Oleg

1 0

cabal-install-3.4.0.0-rc2 and Cabal-3.4.0.0-rc2 are now available
by Oleg Grenrus 03 Sep '20

03 Sep '20

The Cabal developers are happy to announce the first release candidate for cabal-install-3.4.0.0 The corresponding tag are `cabal-install-3.4.0.0-rc2` and `Cabal-3.4.0.0-rc2` https://github.com/haskell/cabal/releases/tag/cabal-install-3.4.0.0-rc2 https://github.com/haskell/cabal/releases/tag/Cabal-3.4.0.0-rc2 and there is a handful of binaries available at https://oleg.fi/cabal-install-3.4.0.0-rc2/ Ubuntu-16.04 bindist should work on most recent Linux distributions, (requires at least kernel 3.15, compiled against glibc-2.23). Similarly darwin-sierra bindist should work on newer macOSes as well. Since the first release candidate (rc1) following issues were resolved: - Bump process version required for job support to 1.6.9 https://github.com/haskell/cabal/issues/6986 - GHC-8.12 is GHC-9.0 https://github.com/haskell/cabal/issues/7019 - cabal-install-head v2-install fails to process source-repository-package https://github.com/haskell/cabal/issues/7007 cabal-install-3.4 release highlights are: - Support for upcoming GHC-9.0 - Removal of sandboxes - Improved public sublibrary support - `active-repositories` configuration - Various `cabal init` improvements - Various `cabal sdist` improvements - `source-repository-package` are not treated as local packages - Added `list-bin` command Complete release notes (drafts) are at: https://github.com/haskell/cabal/tree/master/release-notes Please do test this release and let us know if you encounter any issues: https://github.com/haskell/cabal/issues - Oleg P.S. Unfortunately I discovered yet another bug in cabal sdist behavior, which is triggered if you have packages with data-files. So there will be third release candidate.

1 0

Cabal-3.4 release candidate 1
by Oleg Grenrus 28 Jul '20

28 Jul '20

Dear all, Last week I tagged Cabal-3.4 release candidate. After fixing few immediately obvious issues with cabal-install, I have successfully used it for a week. This week I have been working on improving scripts for bootstrapping and release packaging, and as intermediate result there are - x86_64-darwin-sierra - x86_64-ubuntu-14.04 - x86_64-alpine-3.11.6 - amd64-freebsd-12.1-RELEASE - aarch64-ubuntu-18.04 bootstrapped builds at https://oleg.fi/cabal-install-3.4.0.0-rc1-bootstrapped/ The ubuntu-14.04 build works on later ubuntu, debian, and centos which I tried (in docker). Note, alpine build is not static, i.e. it dynamically links against musl. Please try these out, especially try to build cabal-install (from 3.4) branch, and use it, so we can fix most of regressions since 3.2. I'm specially interested whether the darwin/macos build works on newer macos versions. The release notes for Cabal-3.4 and cabal-install-3.4 are available at https://github.com/haskell/cabal/tree/master/release-notes - Oleg

2 2

Release 3.4 planning
by Oleg Grenrus 14 May '20

14 May '20

Dear cabal developers and users As GHC-8.12 release plan was announced [1]. I suggest that we cut the 3.4 branch at the end of June, i.e. after the first GHC-8.12 alpha release. I opened an issue for discussion: [2] https://github.com/haskell/cabal/issues/6757 --- I renamed previously existing 3.4 milestone to "Considered for 3.4". [3] At the moment there are 64 open issues. I will go though them ASAP. - if there is an assignee ping them, whether they are working on the issue - if positive, we'll add it to 3.4 milestone - assign few unassigned issues to myself, which I think I could complete - I already started work on the last mile/yard/foot of public multi-libraries. At the end of May (in two weeks), I'll remove "Considered for 3.4" issues. The goal is that the issues in release milestones have someone working on them (i.e. they are assigned to someone). The reasoning for above is that we most likely won't resolve all of the 60 issues, and we have "priority: low" and "priority: high" labels to hint "how soon we should start working on them". Please bring other issues (not in "Considered for 3.4") milestone in issues #6757 [2], if you will work on them. Especially if they are clear tasks, which don't require bikeshedding. --- Also the special highlight: We removed sandboxes for cabal-install-3.4 https://github.com/haskell/cabal/issues/6445 Related to the issued of the `cabal install --lib` which is not exactly bug free. That might prevent transition to v2-build for someone. There is an issue about separating that functionality into a subcommand for package environment management. The comment [4] sketches the design. Please read though the issue and feel free to ask questions like "how I would..." if you have any. This way we can make good initial design. (I'm spoiled by cabal-env design, but I haven't found an issue which won't fit into its way of working). Unfortunately I'd leave this feature out of 3.4 as we don't have clear and agreed design. - Oleg [1]: https://mail.haskell.org/pipermail/ghc-devs/2020-May/018851.html [2]: https://github.com/haskell/cabal/issues/6757 [3]: https://github.com/haskell/cabal/issues?q=is%3Aopen+is%3Aissue+milestone%3A… [4]: https://github.com/haskell/cabal/issues/6481#issuecomment-620865817

1 0

Official procedure to build from source bundled with GHC source tarball?
by Compl Yue 10 Feb '20

10 Feb '20

Hello folks, I'm trying to install cabal after built ghc 8.8.2 on smartos, seems the src bundled within ghc src tarball not working: |[root@hswander /build/ghc-8.8.2/libraries/Cabal/cabal-install]# ./bootstrap.sh ||| |||Using gcc for C compiler. If this is not what you want, set CC.||| |||Using /opt/local/gcc7/libexec/gcc/x86_64-sun-solaris2.11/7.4.0/collect2 instead.||| |||Checking installed packages for ghc-8.4.4...||| |||deepseq is already installed and the version is ok.||| |||binary is already installed and the version is ok.||| |||time is already installed and the version is ok.||| |||transformers is already installed and the version is ok.||| |||mtl is already installed and the version is ok.||| |||text is already installed and the version is ok.||| |||parsec is already installed and the version is ok.||| |||network-uri-2.6.1.0 will be downloaded and installed.||| |||network-2.7.0.0 will be downloaded and installed.||| |||HTTP-4000.3.12 will be downloaded and installed.||| |||zlib-0.6.2 will be downloaded and installed.||| |||random-1.1 will be downloaded and installed.||| |||stm is already installed and the version is ok.||| |||hashable-1.2.7.0 will be downloaded and installed.||| |||async-2.2.1 will be downloaded and installed.||| |||base16-bytestring-0.1.1.6 will be downloaded and installed.||| |||base64-bytestring-1.0.0.1 will be downloaded and installed.||| |||cryptohash-sha256-0.11.101.0 will be downloaded and installed.||| |||resolv-0.1.1.1 will be downloaded and installed.||| |||mintty-0.1.2 will be downloaded and installed.||| |||echo-0.1.3 will be downloaded and installed.||| |||edit-distance-0.2.2.1 will be downloaded and installed.||| |||ed25519-0.0.5.0 will be downloaded and installed.||| |||tar-0.5.1.0 will be downloaded and installed.||| |||digest-0.0.1.2 will be downloaded and installed.||| |||lukko-0.1.1 will be downloaded and installed.||| |||hackage-security-0.6.0.0 will be downloaded and installed.||| |||Cabal-3.0.1.0 will be downloaded and installed.||| |||| |||Downloading Cabal-3.0.1.0...||| ||| % Total % Received % Xferd Average Speed Time Time Time Current||| ||| Dload Upload Total Spent Left Speed||| ||| 0 0 0 0 0 0 0 0 --:--:-- 0:00:02 --:--:-- 0||| |||curl: (22) The requested URL returned error: 404 Not Found||| |||| |||Error during cabal-install bootstrap:||| |||Failed to download Cabal.||| |||[root@hswander /build/ghc-8.8.2/libraries/Cabal/cabal-install]# | I wonder what's the official way to do it? btw, I don't know why I can not send msg to the freenode #cabal channel: | (15时11分28秒) ComplYue: ping (15时11分28秒) Cannot send to nick/channel| ||Thanks with best regards, Compl

2 2

Issue with multi public library feature on Cabal 3.0
by Good boy 21 Jan '20

21 Jan '20

Hi All, I'm currently having issue with the multi public library feature on Cabal 3.0. I have a `main` package that has a dependency on `sub` package that exports main and sub library build-depends: sub:{sub, sublib} But when I try to build it, I got an error saying cabal: Encountered missing or private dependencies: sub : {sub, sublib} ==0.1.0.0 I have `visibility: true` on my library stanza, and I have cabal-install 3.0 installed, I couldn't figure out what's wrong. I've come across this issue https://github.com/haskell/cabal/issues/6039, and I'm not sure whether it's related to my issue. Here's an example of the code I have: https://github.com/jeffhappily/test Best regards, Jeff

2 1

Running just one of the integration tests
by Erik de Castro Lopo 17 Jun '19

17 Jun '19

Hi all, I would like to have a go a tackling an issue I am having with cabal and doctests. How do I run a single integration test with the cabal version I have just built out of git? eg cabal-install/tests/IntegrationTests2/targets/simple Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

1 2