- cabal-devel - Haskell.org

Re: [Haskell-cafe] Integrate GHC-API with Cabal
by Imants Cekusins 25 Jul '18

25 Jul '18

cabal-install package includes useful modules. With these modules it is possible to read the actual build info. These modules could be added to the Cabal API. What are the reasons cabal-install can not be added as a project dependency? Can some modules be moved from cabal-install to Cabal library? On 25 July 2018 at 11:33, Félix Baylac <felix(a)alternativebit.fr> wrote: > Dear cafe, > > I am currently working on a project [1] which aims to index the code > published on > Stackage in order to provide a "code example" database. Basically, for each > library, I want to generate a real-world example corpus for each exported > symbol. > > Before generating this database, I need to retrieve the exported symbol of > a > package. So far, I have been gathering the dependencies and integrating > them in > the GHC pkg database using an external stack call, I then parse the cabal > file > and load the exposed modules using the GHC API and gather the exported > symbols*. > > It works pretty reliably on the simple packages, however, I end up with > some > missing dynamic flags for some more advanced packages (missing c includes, > c > libraries, ASM flags, etc.). I then started to parse and load these > missing > attributes to GHC until I stepped back for a moment and realized I was > re-implementing cabal build. > > I then looked for a way to "hook" my GHC API code in cabal build. This > would > allow cabal to both handle the dependencies gathering as well as setting > up the > correct GHC dyn-flags. The only resource I found was [2]. It's really > clever, > however, looks a bit hacky to me. > > Is there a better way to perform this kind of "hook"? > > > [1] https://git.alternativebit.fr/NinjaTrappeur/Exhs > [2] http://blog.ezyang.com/2017/02/how-to-integrate-ghc-api- > programs-with-cabal/ > > * I am aware of the hoogle index generated by haddock. However, this index > is > missing when the haddock documentation of a package cannot be generated. > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post.

1 0

Cabal website
by Imants Cekusins 19 Jun '18

19 Jun '18

Hi all, Re: https://github.com/haskell/cabal/issues/4013 Would https://ciezbit.bitbucket.io/cabal/doc be an improvement over https://www.haskell.org/cabal/ ? This link points to a temporary demo deployment. The app is written in React with material-ui lib.

5 11

Bikeshedding (new-)repl's commandline UI
by Merijn Verstraaten 08 May '18

08 May '18

Ok, so this email concerns two main thing I wanted to run by people before I invest the effort. So in my "avoid recompilation sage" [1] I've run into an issue where reducing local recompilation ends up throwing away flags intended for ghci when running "cabal new-repl". Stemming from a mix of throwing away flags that don't affect build output and the fact that the only way to pass options to ghci at the moment is via "--ghc-option". (See the last 2 comments in the PR for details). So the solution proposed in the PR was to add a separate "--ghci-option", which leads two issues: 1) All current new-X command have a "CommandUI" that basically mimics the original "install" command in what it returns (i.e. "CommandUI (ConfigFlags, ConfigExFlags, InstallFlags, HaddockFlags)"). Is there a specific reason they're all the same, or is it just a matter of "we haven't had a need to expand any of them yet?". In other words, can I simply extend "replCommand" to take extra flags returned in their own data structure? 2) Secondly, in the PR I proposed "--ghci-option", but that'd honestly result in rather tricky overlap with configured programs, possible undoing part of the work to avoid building configurations, etc. It's also highly GHC specific. I was wondering whether it wouldn't be better to simply add a "--repl-option" instead which just forwards it's arguments to whatever REPL command that happens to get invoked. The added bonus of this approach is that it'd be fairly trivial to apply the same approach to old "repl" so that it works with Setup.hs too (if that's desired). Cheers, Merijn [1] - https://github.com/haskell/cabal/pull/5287

1 0

draft proposal on provenance-qualified dependencies
by Gershom B 13 Mar '18

13 Mar '18

Hey all, I mentioned (on the long SLURP thread) that I was thinking about a general proposal for provenance-qualified dependencies to reduce coupling in the haskell ecosystem. Having worked it out a bit, I think the bigger win is it also provides a way to specify dependencies on git repos, etc., which has been an oft-requested feature. I don't want to submit it as an ecosystem proposal proper without further polish, and I held off on bugging a larger audience of cabal folks until the 2.2 branch was cut. So now I'm passing this along for further comment and polish before I make a real proposal: https://github.com/gbaz/ghc-proposals/blob/patch-1/proposals/0000-provenanc… There's no urgency, but it would be good to get some feedback in the next few weeks if possible. Cheers, Gershom

2 4

Upgrading Stack to Cabal 2.2
by Michael Snoyman 21 Feb '18

21 Feb '18

Hi all, Oleg mentioned to me on Reddit that a 2.2 branch has been cut for Cabal, and recommended we try to upgrade Stack to it. I'm sharing information here on that process in case it's useful to others, either as feedback on the API changes, or help for others going through similar upgrades. If anyone would rather that I do or do not post such reports in the future, let me know. I've opened a PR for this change[1], which currently is a single commit[2]. As you can see from the change to stack.yaml[3], I needed to refer to the commit of Cabal in question, and turn on `allow-newer` for some packages (cabal-doctest and http-api-data) with restrictive upper bounds on Cabal. Both of these packages compiled without issue. No change was necessary to Stack's Setup.hs file. Most of the changes so far were compile-time errors, which is a Good Thing. Changes I had to make: * The build type is no longer a Maybe field. (As a user: this is a nice change, no longer a need to guess about what a Nothing value means.) * There are now two License types, the original one and the SPDX variant. I don't understand what this change is about, some further explanation in the docs or the ChangeLog would definitely be appreciated. But hacking my way through the types seems to have worked. * Parsing a package description now works on a ByteString instead of a String. This allowed me to remove some UTF8 conversion and BOM-stripping code, which is very nice. * The new parsing API exposes the cabal file version when that prevented the parse (at least, that's my understanding). The changes to accommodate the new API were relatively trivial, so another +1 here. * Also: getting file position information for warnings and errors is _very_ nice. +1 I haven't done extensive testing yet, but I've so far only found one bug due to runtime changes: the behavior of allBuildInfo has changed to now include non-buildable components. This resulted in some confusion until I reviewed the changelog more closely. If I could make a request, it would be that, in the future, new runtime behavior come with a new function name, to convert runtime errors into compile time errors. This was _not_ a particularly difficult issue to work around though, in large part thanks to the changelog. I'll continue testing this branch of Stack. Our plans are to merge this to master, and release Stack 1.7.0 close to the Cabal 2.2 release date. Michael [1] https://github.com/commercialhaskell/stack/pull/3878/files [2] https://github.com/commercialhaskell/stack/pull/3878/commits/a101341d04213d… [3] https://github.com/commercialhaskell/stack/pull/3878/commits/a101341d04213d…

4 8

2.2 release branch created
by Mikhail Glushenkov 15 Feb '18

15 Feb '18

Hi *, I've just created the branch for the 2.2 Cabal/cabal-install release [1]. If everything goes according to plan, the final release will be out approximately in two weeks' time, i.e. around the end of the month. This is a delay of one month compared with the original plan shared in the previous status update [2]. Hopefully, this time there won't be any more additional delays. Cheers, Mikhail [1] https://github.com/haskell/cabal/tree/2.2 [2] https://mail.haskell.org/pipermail/cabal-devel/2017-December/010410.html

1 0

Gearing up for the 2.2 release
by Mikhail Glushenkov 28 Dec '17

28 Dec '17

Hi *, It is time to start planning for the 2.2 release of Cabal/cabal-install. The original plan was to do it before the end of the year, however, given the current state of HEAD and the fact that GHC 8.4 is going to be released in February, I think it won't be a tragedy if we delay 2.2 a little. My current plan is to cut the 2.2 branch around January 15th, and make the release 2-3 weeks after that. So please hurry if there's something you absolutely want to get into 2.2. Current release blockers/stuff that I really want to see included: * Herbert's work on the forwards-compat scheme (https://github.com/haskell/cabal/issues/4899) * Duncan's target package names stuff (https://github.com/haskell/cabal/pull/4889) * Oleg's remaining parser PRs and SPDX work. * Some other currently unmerged PRs that are not marked blocked or are easy to get into mergeable shape. Cheers, Mikhail

3 4

Cabal/cabal-install project ideas for Summer of Code 2018
by Mikhail Glushenkov 27 Dec '17

27 Dec '17

Hi *, As you are probably aware, it is again the time of the year to come up with project proposals for the next year's Summer of Code [1]. I've started a Wiki page for collecting Cabal/cabal-install HSoC 2018 project ideas [2] - please feel free to add new entries, edit existing ones and add/remove yourself to/from the list of potential mentors. Once the list of potential projects is more or less complete, I'll send a PR to the Summer of Haskell GitHub repo. Herbert tells me that the list of proposals should be finished before January 4th, so please hurry! Cheers, Mikhail [1] https://mail.haskell.org/pipermail/haskell-cafe/2017-December/128365.html [2] https://github.com/haskell/cabal/wiki/%5BG,H%5DSoC-2018-Project-Ideas

1 0

[ANN] Cabal 2.0.1.1/cabal-install 2.0.0.1 released
by Mikhail Glushenkov 08 Dec '17

08 Dec '17

Hi *, Cabal 2.0.1.1 and cabal-install 2.0.0.1 are now available from Hackage and the download page: http://hackage.haskell.org/package/Cabal-2.0.1.1 http://hackage.haskell.org/package/cabal-install-2.0.0.1 https://www.haskell.org/cabal/download.html Changes in this release: Cabal 2.0.1.1: * Don't pass `other-modules` to stub executable for detailed-0.9 (#4918). * Hpc: Use relative .mix search paths (#4917). cabal-install 2.0.0.1: * Support for GHC's numeric -g debug levels (#4673). * Demoted 'scope' field version check to a warning (#4714). * Fixed verbosity flags getting removed before being passed to 'printPlan' (#4724). * Added a '--store-dir' option that can be used to configure the location of the build global build store (#4623). * Turned `allow-{newer,older}` in `cabal.project` files into an accumulating field to match CLI flag semantics (#4679). * Improve success message when `cabal upload`ing documentation (#4777). * Documentation fixes. Cheers, Mikhail

1 0

new cabal install binaries
by Gershom B 08 Dec '17

08 Dec '17

when we build the new platform we're going to have new cabal-install binaries for 2.0.1.0. It would be better if we provided the same ones as provided on the cabal website. Is there anyone lined up to build any of these, or would you like the platform team to provide you with the binaries we build as well? (i know i've done mac in the past, and will happily do so again, but typically there have been other sources for linux and windows binaries). Cheers, Gershom

2 2