- cabal-devel - Haskell.org

installing all of hackage
by Duncan Coutts 01 May '08

01 May '08

All, We're getting nearer to being able to use cabal-install to install all of hackage for us. :-) I did a run this evening: $ cabal install -O0 $(cat pkgs) which is a list of 485 packages. I had to prune this list manually to eliminate the ones that have unsatisfiable dependencies (about 10). I hope to add a flag to get cabal-install to do that automatically, and where we do not use that flag, to produce better error messages saying *which* packages have the unsatisfiable dependencies. So I now have 329 library packages installed. It makes me notice this issue rather acutely: http://hackage.haskell.org/trac/ghc/ticket/2089 "reading the package db is slow" In fact this would be a really big problem for doing our own make-like system where we invoke ghc once for each module. Where at the moment it takes 1 second per library/executable, it'd take one second per module. It would in fact mean that reading the package database would take more time than compilation since compilation zips through at less than one second per module on average with -O0. I've also got a list of 163 install failures. Unfortunately we do not get logs of the failing packages, just a summary like: GuiTV-0.4 depends on wxcore-0.10.3 which failed to install. xtc-1.0 depends on wxcore-0.10.3 which failed to install. phooey-2.0 depends on wxcore-0.10.3 which failed to install. GenI-0.16.1 depends on wxcore-0.10.3 which failed to install. wx-0.10.3 depends on wxcore-0.10.3 which failed to install. AutoForms-0.4.0 depends on wxcore-0.10.3 which failed to install. wxcore-0.10.3 failed during the configure step. The exception was: exit: ExitFailure 2 Still, it's progress I feel. I've also added a flag to let us choose which version of the Cabal lib to use when building packages. This should make it possible to compare building everything with Cabal-1.2 and 1.4 for example. Duncan BTW, if you're wondering about the discrepancy in package numbers, it's because I had some packages installed already, some of which were not from hackage. Some of the packages I installed were binaries for which we do not track the installed state. Also, since some packages were already installed, cabal-install did not re-install them. So I don't know how many did actually install successfully, only how many failed.

1 0

hasLibs and hasExes honest reporting?
by Yaakov Nemoy 01 May '08

01 May '08

Hi List, First off, I want to say hi, as this is my first post. I'm trying to get some badly needed updates to cabal-rpm, so we can get more Haskell packages into Fedora. All of the following is with Cabal 1.2.3.0 and GHC 6.8.2 as packaged in Fedora 8. In the module Distribution.PackageDescription, there are four functions, hasExes, and hasLibs, as well as libModules and exeModules. These functions claim to do the obvious for a PackageDescription. The only problem I'm having is with packages like xmonad, which have both Executables and Libraries. In the case of xmobar, hasLibs returns False, and an empty list for libModules, but True and a list for hasExes and exeModules respectively. In the case of xmonad-contrib, the opposite is true, that is there are no Executables at all, but a bucket load of Libraries. In the case of xmonad, hasLibs returns True. but returns a nonempty list. hasExes returns True, and with the same nonempty list. I would expect the lists to be the same, as all the Modules listed therein are needed to compile the executable, and also to be linked with the user supplied config file. The only problem I see is with hasLibs itself. I heard something a while back that xmonad needs to be compiled twice, because this setup is considered an edge case in Cabal. Because xmonad is the reason why I'm working on getting Haskell packages into Fedora, I'm not sure I want to think of it that way. Is this a bug, or just a 'feature' I need to watch out for? Cheers, Yaakov Nemoy

3 5

patch applied (cabal-branches/cabal-1.4): Add help command as per ticket #272
by Duncan Coutts 30 Apr '08

30 Apr '08

Wed Apr 30 06:37:40 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Add help command as per ticket #272 "cabal help" behaves like "cabal --help" "cabal help cmd" behaves like "cabal cmd --help" Should still work with command line completion. M ./Distribution/Simple/Command.hs -15 +42 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/2008043013…

1 0

patch applied (cabal): Add help command as per ticket #272
by Duncan Coutts 30 Apr '08

30 Apr '08

Wed Apr 30 06:37:40 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Add help command as per ticket #272 "cabal help" behaves like "cabal --help" "cabal help cmd" behaves like "cabal cmd --help" Should still work with command line completion. M ./Distribution/Simple/Command.hs -15 +42 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080430133740-adfee-f518b225…

1 0

[Hackage] #272: Support 'cabal help' in addition to 'cabal --help'
by Hackage 30 Apr '08

30 Apr '08

#272: Support 'cabal help' in addition to 'cabal --help' ---------------------------------+------------------------------------------ Reporter: tibbe | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ Many tools with a Cabal like interface (e.g. darcs, git, subversion, perforce) support {{{ <program name> help [<command>] }}} where leaving out the command gives the same behavior as {{{ <program name> --help }}} Supporting the same interface as may other tools would be nice for new users (who are likely to type help!) and experienced users as well (same syntax for all your tools). The first, and probably easiest thing would be to just support 'cabal help' but I would be nice with 'cabal help <command>' as well. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/272> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

patch applied (cabal-install): Remove the resolveDependenciesLocal, implement it via resolveDependencies
by Duncan Coutts 30 Apr '08

30 Apr '08

Wed Apr 30 12:33:51 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Remove the resolveDependenciesLocal, implement it via resolveDependencies The local variant was for the case that we were starting from a package description rather than a dependency to a named package. In the local case we not only need to resolve the dependencies of the package but also to find a flag assignment for the local package. This case crops up in the resolver normally when we try to satisfy a dependency, we have to pick a flag assignment for the dependency and resolve its dependencies. It is annoying to have both entry points, especially as we want the resolver to be plugable. So instead we define the local package as an available package, then by resolving a single dependency on exactly the name and version of the local package then we can get an install plan for the local package. It also requires generalising installPkg to deal with the local case. M ./Hackage/Dependency.hs -19 M ./Hackage/Install.hs -13 +35 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080430193351-adfee-…

1 0

patch applied (cabal-install): Generalise and rename PkgInfo to include local packages
by Duncan Coutts 30 Apr '08

30 Apr '08

Wed Apr 30 11:09:22 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Generalise and rename PkgInfo to include local packages Renamed to AvailablePackage since that what it is really. Now instead of just representing packages from a remote hackage repo it includes an alternative for a local unpacked package. In future we should add more alternatives, eg for other local packages (ie not just the one that's unpacked in the current dir) and for remote packages in source control like darcs, git etc. M ./Hackage/DepGraph.hs -1 +1 M ./Hackage/Dependency.hs -16 +18 M ./Hackage/Fetch.hs -7 +34 M ./Hackage/IndexUtils.hs -10 +12 M ./Hackage/Install.hs -6 +8 M ./Hackage/InstallPlan.hs -4 +4 M ./Hackage/List.hs -5 +5 M ./Hackage/Types.hs -31 +20 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080430180922-adfee-…

1 0

Announcing decision diagrams
by Josef Svenningsson 30 Apr '08

30 Apr '08

Hi, A few weeks ago during the Hackathon in Gothenburg I started working on a library for decision diagrams. The purpose was to use it in cabal-install when figuring out which packages should be installed and which version of them to choose. Why do we need something as complex as decision diagrams for that? Simply because the problem is NP-complete in general. Now, heuristics might do a good job at solving this problem but it might be wise to have something like this library as a fall-back. So, I'm happy to announce the first version of my decision diagram library. The darcs repo can be found here: http://www.cs.chalmers.se/~josefs/decisiondiagram The status of the library is as follows: I'm beginning to trust the correctness of the implementation. There are a few tests in place and although I have more tests in mind the testing that I have already done gives me quite a bit of confidence. As to the speed of the library: it's pretty poor. I've used most of the tricks in the book on implementing decision diagrams so complexity wise it should be like any other BDD implementation except for a few log factors here and there. But I haven't cared anything about constant factors, so the wall clock performance is pretty weak. As a benchmark I wrote a small sudoku solver but my library choked on even an easy puzzle. I nevertheless feel that this library is a good starting point and that it will be able to handle all current packages that we have easily. I am aware that the is a GSOC project coming up which is supposed to tackle this issue as well. This package is by no means meant to supersede that project before it has begun. I think we can benefit from several approaches here since the underlying problem is NP-complete and thus it's probably wise to evaluate more than one option. I haven't looked into how to use this package in cabal-install yet, but I suspect it will be fairly easy. I'd appreciate any comments and help on that though since I'm not familiar with the cabal-install code base yet. Happy cabaling, Josef

2 3

patch applied (cabal-install): Convert the Install module to use the new SetupWrapper
by Duncan Coutts 30 Apr '08

30 Apr '08

Wed Apr 30 04:50:21 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Convert the Install module to use the new SetupWrapper And refactor slightly to batch some of the misc parameters together in a record rather than passing them all separately. M ./Hackage/Install.hs -49 +85 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080430115021-adfee-…

1 0

patch applied (cabal-install): Add a new --cabal-lib-version flag to the install command
by Duncan Coutts 30 Apr '08

30 Apr '08

Wed Apr 30 04:47:09 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Add a new --cabal-lib-version flag to the install command It's used to select which version of the Cabal lib to use when configuring, building and installing packages. It's mainly so that we can use cabal-install to help us test that packages build ok with both old and new versions of the Cabal library. In particular we'd like to check every package on hackage to make sure that new Cabal versions are not breaking packages that worked with older versions. M ./Hackage/Setup.hs -15 +36 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080430114709-adfee-…

1 0