October 2013 - cabal-devel

What's next?
by Johan Tibell 11 Nov '13

11 Nov '13

Hi all, With 1.18 out the door it's time to look towards the future. Here are the major themes I'd like to see us work on next: ## Faster builds There are several interesting things we could do and are doing here. * Avoid relinking if possible. This reduces incremental build times (i.e. when you run cabal build after making some change) by avoiding relinking e.g. all the test suites and/or benchmarks. See https://github.com/haskell/cabal/pull/1410 for some in-progress work. * Build components and different ways (e.g. profiling) in parallel. We could build both profiling and non-profiling versions in parallel. We could also build e.g. all test suites in parallel. The key challenge here is to coordinate all parallel jobs so we don't spawn too many. See https://github.com/haskell/cabal/pull/1413 * Build modules in parallel. This fine granularity would let us making building a single package faster, which is the most common case after all. There has been some GSoC work here e.g. http://hackage.haskell.org/trac/ghc/ticket/910 and some work by Mikhail. ## Do the right thing automatically The focus here should be on avoiding manual steps the cabal could do for the user. * Automatically install dependencies when needed. When `cabal build` would fail due to a missing dependency, just install this dependency instead of bugging the user to do it. This will probably have to be limited to sandboxes where we can't break the user's system * GHCi support could be improved by rebinding :reload to rerun e.g. preprocessors automatically. This would enable the users to develop completely from within ghci (i.e. faster edit-save-type-error cycle). We have most of what we need here (i.e. GHC macro support) but someone needs to make the final change to generate a .ghci file to pass in the ghci invocation. ## Support large projects We need to better support projects with tens or hundreds of packages. As projects grow it's naturally to split them up into a bunch of packages (libraries and executables). Some changes to the project might need changes across a couple of packages (e.g. to a supporting library and to an executable) in a single change and developers need to be able to * build several packages that have local changes, and * share changes to packages with other developers without making a release to some local Hackage server every time. Both can be done by having a single source repo with all the packages and using `cabal sandbox add-source` to make sure they get built when needed. However, that method only scales up to a handful of packages. I think we want to think about moving away from a world where all cabal commands are run in the context of some "current" package (i.e. in the current working directory). I think we want to be able to stand in the root directory of some source repo and build things from there. Example: $ git clone git://my-company/repo my-project $ cd my-project $ ls lib-pkg1 lib-pkg2 exe-pkg1 exe-pkg2 ... $ cabal sandbox init # or something similar $ edit lib-pkg1/Lib.hs $ edit exe-pkg1/Exe.hs $ cabal build exe-pkg1 # picks up changes to lib-pkg1 This has implication for many things e.g. where the .cabal-sandbo and the dist directories are kept. Perhaps dist would have a subdirectory per package (right now we do something similar for sandbox dependencies). I imagine that the syntax for e.g. cabal build would have to extended to cabal build [[DIR':']COMPONENT] Example: cabal build lib-pkg1:some-component Similar for `cabal test` and `cabal bench`. Cheers, Johan

9 16

cabal-install-1.18 on GHC-6.12
by Henning Thielemann 30 Oct '13

30 Oct '13

I am trying to compile cabal-install-1.18.0.2 on GHC-6.12.1. It aborts with: ... [12 of 73] Compiling Distribution.Client.Compat.Semaphore ( Distribution/Client/Compat/Semaphore.hs, dist/build/cabal/cabal-tmp/Distribution/Client/Compat/Semaphore.o ) Distribution/Client/Compat/Semaphore.hs:12:26: Module `Control.Exception' does not export `mask_' That is, you must either narrow the dependency on 'base' or avoid 'mask_'.

5 6

how to package cabalized binaries with assets for a package manager?
by Carter Schonwald 28 Oct '13

28 Oct '13

Hey All, the mac homebrew folks are trying to understand how they can distro haskell tools like Pandoc, and I"m out of my league in terms of the cabal / cabal-install sandbox fu needed for them to do it correctly, esp since Pandoc is one of those tools that needed a bunch of asset files installed, could someone who's more comfortable / familiar with how to do it right step in to help em out? http://librelist.com/browser//homebrew/2013/10/25/building-ghc-takes-30-min… thanks -Carter

2 2

Re: Hackage 'changelog' display (was: Fwd: [commit: packages/stm] master: Refactor & update `stm.cabal` to `cabal-version>=1.10` (aa4774b))
by Duncan Coutts 25 Oct '13

25 Oct '13

On Fri, 2013-10-18 at 16:05 +0200, Herbert Valerio Riedel wrote: > Hello Duncan, > > ...any recommendation on this one? For isntance, how do I best add a link from the > description-field pointing to the changelog file? No I think the longer term solution is to treat the changelog properly in some machine-readable form so that hackage can show the changes in a reasonable way, e.g. most recent changes, expand to more detail. I don't think we really want to have the current situation where some packages have these huge descriptions including long changelogs and others have nothing. It's all rather inconsistent. We should probably have hackage show only the first ~20-30 lines of the description and let the user expand that if they want to see more, and do a similar thing for the changelog. Simon makes the point that he likes having the changelog in the .cabal file rather than a separate file because it's less mental effort to update, as you can see it at the same time as the version. So perhaps what we should do is add a changelog field to the .cabal file an allow that to be inline, or to refer to a file, e.g. "changelog:" or "changlog-file:". Either way we can then do a bit of simple syntax checking so we know we can format it ok on hackage and in other tools. Duncan

2 1

hackage reverse dependencies
by Jens Petersen 14 Oct '13

14 Oct '13

Not really complaining :) but one of the things I had been looking forward to with Hackage2 was the display of reverse-dependencies, but I gather it was disabled for now (because it loads the server too much when updating the data iirc?). I was thinking perhaps a compromise would be to show only direct reverse-dependencies rather than including all indirect dependencies too. Perhaps that would make it scale better? I think direct dependency information is the most useful anyway (and also what packdeps provides). Before doing anything I thought I would ask here first if this makes sense and should be work? I for one would still really like to see basic reverse dependencies info listed on hackage (I noticed yesterday that npm has them too). Jens

5 5

Hackage updating of distro data
by Jens Petersen 14 Oct '13

14 Oct '13

Hi, it is great that Hackage 2 finally was deployed in production. :-) How often does Hackage 2 update/pull distro data? Hackage 1 had a cronjob I believe which ran every few hours I think. But the new Hackage does not seem to pull often/regularly. For Fedora I updated the data on 18 Sept and then 26 Sept. The update from 18th Sept is reflected in Hackage but not 26th Sept. Checking more I guess the 18 Sept was still during Hackage1 so it looks like Hackage2 has not updated it distro data since going into production? Is there a cronjob setup on the new hackage server currently for pulling distro package data? Thanks, Jens

2 2

Feature Idea: --no-remote-fetching flag
by Adam Foltzer 08 Oct '13

08 Oct '13

Hello, With the wonderful advent of sandboxes in mainline cabal, I'd like to see what folks think of a flag to disable remote fetching of dependencies. The idea is that one could `cabal sandbox add-source` a set of trusted dependencies, and then be assured that a subsequent `cabal install --no-remote-fetching` would *only* resolve dependencies in that trusted set. I'd be willing to explore implementing this myself, if it would be appropriate for a first-time cabal hacker. I'm also quite interested to hear whether this would be a useful feature for others, or other ways you might propose to address the problem. I also understand that I can get this behavior by modifying the ~/.cabal/config, but this is a kludgey approach that is not workable in all deployment environments. Thanks! Adam

4 5