September 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

ANN: Cabal v1.18.0 released
by Johan Tibell 16 Sep '13

16 Sep '13

Hi all, On behalf of the cabal maintainers and contributors I'm proud to announce the Cabal (and cabal-install) 1.18.0 release. To install run cabal update && cabal install Cabal-1.18.0 cabal-install-1.18.0 With 854 commits since the last release there are two many improvements and bug fixes to list them here, but two highlights are: * Hermetic builds using sandboxes. This should reduce the number of "dependency hell" and broken package DB problems. * GHCi support. It's now much easier to use ghci when developing your packages, especially if those packages require preprocessors (e.g. hsc2hs). Here's how working on a package might look like using the new features: # Only once: cabal sandbox init cabal install --only-dependencies --enable-tests # Configure, build, and run tests: cabal test # now implies configure and build # Play around with the code in GHCi: cabal repl Mikhail wrote a bit more about the user visible changes on his blog: http://coldwa.st/e/blog/2013-08-21-Cabal-1-18.html For a complete list of changes run git log cabal-install-v1.16.0.2..cabal-install-v1.18.0 in the cabal repo or look at the GitHub compare page: https://github.com/haskell/cabal/compare/cabal-install-v1.16.0.2...cabal-in… (only shows the last 250 commits). 57 people contributed to this release! 503 Mikhail Glushenkov 99 Johan Tibell 41 Duncan Coutts 39 Ian Lynagh 19 Brent Yorgey 19 Thomas Tuegel 18 Ben Millwood 16 Eyal Lotem 10 Thomas Dziedzic 7 Andres Loeh 6 John Wiegley 6 Benno Fünfstück 5 Gregory Collins 4 Herbert Valerio Riedel 4 Simon Hengel 3 Joachim Breitner 3 Luke Iannini 3 Bryan Richter 3 Richard Eisenberg 3 Tuncer Ayaz 3 Jens Petersen 2 Arun Tejasvi Chaganty 2 Bryan O'Sullivan 2 Eric Kow 2 Jookia 2 Paolo G. Giarrusso 2 Paolo Capriotti 1 Sönke Hahn 1 Yitzchak Gale 1 Albert Krewinkel 1 stepcut 1 Alexander Kjeldaas 1 Austin Seipp 1 Bardur Arantsson 1 Ben Doyle 1 Ben Gamari 1 Bram 1 Carter Tazio Schonwald 1 Clint Adams 1 Daniel Wagner 1 David Lazar 1 Erik Hesselink 1 Eugene Sukhodolin 1 Gabor Greif 1 Jack Henahan 1 Jason Dagit 1 Ken Bateman 1 Mark Lentczner 1 Masahiro Yamauchi 1 Merijn Verstraaten 1 Michael Thompson 1 Niklas Hambüchen 1 Oleksandr Manzyuk 1 Patrick Premont 1 Roman Cheplyaka 1 Sergei Trofimovich 1 Stephen Blackheath -- Johan, on behalf of the cabal maintainers and contributors.

4 4

How can I get SSH access to www.haskell.org to upload the Cabal user guide?
by Johan Tibell 11 Sep '13

11 Sep '13

Hi all, Who manages www.haskell.org? Where's the machine? How can I get an SSH account so I can upload the Cabal user guide for the Cabal version I just released? -- Johan

5 6

Lag in new hackage mirroring of old hackage
by Gregory Weber 11 Sep '13

11 Sep '13

Hello, I want to report some lag in the mirroring of old hackage by the new hackage. "Note: we are mirroring packages from the old server (currently every 30min) so it is suitable to use as your main hackage server with some caveats: because we are allowing package authors to upload (as well as the mirroring) then you may find a slightly different set of packages on this server. " -- http://new-hackage.haskell.org/ viewed on August 2, 2013 But for some elm packages, I just noticed today, the versions on new hackage are considerably more than 30 minutes older than those on old hackage: Elm: new hackage 0.7.1.1 uploaded January 25, 2013 old hackage 0.8.0.3 uploaded May 28, 2013 elm-server: new hackage 0.7 uploaded January 4, 2013 old hackage 0.8 uploaded May 22, 2013 I've been happily using the new hackage for some weeks now, and occasionally enjoying the new features. Other than this lag, it's been a good experience. Thanks! -- Gregory D. Weber, Ph. D. http://mypage.iu.edu/~gdweber/ Associate Professor of Informatics Tel (765) 973-8420 Indiana University East FAX (765) 973-8550

3 2

Hackage 2 trustees
by Erik Hesselink 11 Sep '13

11 Sep '13

Hi all, I just upgraded our internal hackage to the latest HEAD. I found that the behavior of the 'trustees' group has changed. Previously, they could upload any (existing) package, but that doesn't work anymore. This functionality was very useful for us, since otherwise, we'd have to add all our coders as maintainers to all our packages. I've patched our local code, but my question is: * Is this a bug and should I push a patch? * Is this intended and should I push a patch to the text at http://hackage.typlab.com/packages/trustees/, since it doesn't correspond to the current behavior? Regards, Erik

2 1

One week before Cabal in GHC 7.8 cutoff
by Johan Tibell 09 Sep '13

09 Sep '13

Next Monday is the feature freeze for GHC 7.8. That means that we should try to fix any critical bugs in the Cabal library before that so we ship a solid version of Cabal together with GHC. As of today there's only one unreleased commit to Cabal-1.18.0.

1 0

Keeping the cabal website in the git repo
by Johan Tibell 08 Sep '13

08 Sep '13

Hi all, While the sources of some of the documentation is already in git, much of the website (http://www.haskell.org/cabal/) isn't. I suggest we check it in under a website/ directory, next to the Cabal and cabal-install directories. -- Johan

3 2

Re: [Haskell-cafe] ANN: Cabal v1.18.0 released
by Johan Tibell 05 Sep '13

05 Sep '13

I pasted your report into the bug tracker: https://github.com/haskell/cabal/issues/1478 I don't know if you're on GitHub or not so I could link the report to your user. On Thu, Sep 5, 2013 at 8:16 AM, Rogan Creswick <creswick(a)gmail.com> wrote: > I ran into another oddity due to old build artifacts today -- it was easy to > fix, but very confusing; cabal repl was exiting with "unrecognised command: > repl". > > tl/dr; if you see this, delete the old 'dist' dir and re-run 'cabal > configure'. > > Here's a snippit of my shell session to explain in more detail: > > $ cabal sandbox init > ... > $ cabal --version > cabal-install version 1.18.0 > using version 1.18.0 of the Cabal library > $ cabal configure > Resolving dependencies... > Configuring pgftransform-0.0.0.1... > $ cabal repl > unrecognised command: repl (try --help) > $ cabal --help > ... > Commands: > ... > build Compile all targets or specific targets. > repl Open an interpreter session for the given target. > sandbox Create/modify/delete a sandbox. > ... > > Note that cabal --version and cabal --help indicated that repl /was/ a valid > command. > > The issue appears to be that an old dist directory was still hanging around, > and (I suspect) the compiled setup.hs build program (which would have been > built with an old Cabal) was causing the actual error. Deleting the dist > dir and re-running cabal configure set everything right. > > --Rogan > > > On Thu, Sep 5, 2013 at 6:18 AM, Yuri de Wit <ydewit(a)gmail.com> wrote: >> >> It is easy enough to recreate the link manually or as easy to run cabal >> install again, but that is not the point here. The point is that it will >> bite the next dozen of unsuspecting users since, at first, they have no idea >> of what is going on. >> >> In any case, apologies for sending this in this thread as it doesn't seem >> the right forum to discuss it. >> >> >> On Thu, Sep 5, 2013 at 7:53 AM, Paolo Giarrusso <p.giarrusso(a)gmail.com> >> wrote: >>> >>> On Wednesday, September 4, 2013 11:41:33 PM UTC+2, Yuri de Wit wrote: >>>> >>>> Thanks for all the hard work! >>>> >>>> If you see this in OSX (#1009) while installing cabal 1.18: >>>> >>>> Warning: could not create a symlink in /Users/lemao/Library/Haskell/bin >>>> for >>>> cabal because the file exists there already but is not managed by cabal. >>>> You >>>> can create a symlink for this executable manually if you wish. The >>>> executable >>>> file has been installed at >>>> /Users/user/Library/Haskell/ghc-7.6.3/lib/cabal-install-1.18.0/bin/cabal >>>> >>>> You will need to manually remove the pre-existing 1.16 links in >>>> ~/Library/Haskell/bin before installing again. >>> >>> >>> Instead of installing again, you can even just recreate the symlink as >>> mentioned by the message (if you know how to do that). >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >

1 0

Re: [Haskell-cafe] ANN: Cabal v1.18.0 released
by Yuri de Wit 05 Sep '13

05 Sep '13

It is easy enough to recreate the link manually or as easy to run cabal install again, but that is not the point here. The point is that it will bite the next dozen of unsuspecting users since, at first, they have no idea of what is going on. In any case, apologies for sending this in this thread as it doesn't seem the right forum to discuss it. On Thu, Sep 5, 2013 at 7:53 AM, Paolo Giarrusso <p.giarrusso(a)gmail.com>wrote: > On Wednesday, September 4, 2013 11:41:33 PM UTC+2, Yuri de Wit wrote: > >> Thanks for all the hard work! >> >> If you see this in OSX (#1009) while installing cabal 1.18: >> >> *Warning: could not create a symlink in /Users/lemao/Library/Haskell/bin >> for* >> *cabal because the file exists there already but is not managed by >> cabal. You* >> *can create a symlink for this executable manually if you wish. The >> executable* >> *file has been installed at* >> */Users/user/Library/Haskell/ghc-7.6.3/lib/cabal-install-1.18.0/bin/cabal >> * >> >> You will need to manually remove the pre-existing 1.16 links in >> ~/Library/Haskell/bin before installing again. >> > > Instead of installing again, you can even just recreate the symlink as > mentioned by the message (if you know how to do that). >

1 0

Patch for Cabal
by Dominic Steinitz 02 Sep '13

02 Sep '13

Hi Duncan, I finally finished off the patch for https://github.com/haskell/cabal/issues/1460 I was working on with your help at ZuriHac. It's in my fork of cabal here: https://github.com/idontgetoutmuch/cabal/commit/f76ab8b6c0945b82746d664918e… I am not sure what to do next. How should we test it? We need to make sure it doesn't break anything and also that it actually fixes the problem. Curses! I just forgot I don't check which version of cabal is being used so that we pass the old style --constraint rather than the new style --dependency for old cabals. Before I fix that, perhaps you wouldn't mind thinking about testing and also have a look at the code to make sure I haven't done something stupid. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

1 0