- cabal-devel - Haskell.org

[Hackage] #243: Notify maintainers of uploads
by Hackage 20 Feb '08

20 Feb '08

#243: Notify maintainers of uploads ----------------------------------+----------------------------------------- Reporter: ross(a)soi.city.ac.uk | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ----------------------------------+----------------------------------------- Ian suggests: one thing we could do is to e-mail the maintainer address (in both the old and new cabal files) when an upload is done, including the username of the uploader and whether the maintainer address has changed. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/243> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

patch applied (cabal-install): Use a dependency graph rather than a list when installing packages
by Duncan Coutts 20 Feb '08

20 Feb '08

Wed Feb 20 03:06:37 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Use a dependency graph rather than a list when installing packages This allows us to figure out what to do when installing a single package fails. Instead of just carrying on as if nothing had happened and then failing several other packages which depended on the one that failed initially we can cut those dependent packages out as soon as the first one fails and if there is anything left that did not depend on the failed package then we can try and carry on. A ./Hackage/DepGraph.hs M ./Hackage/Dependency.hs -14 +23 M ./Hackage/Fetch.hs -1 +3 M ./Hackage/Info.hs -2 +4 M ./Hackage/Install.hs -13 +21 M ./Hackage/Utils.hs +4 View patch online: http://darcs.haskell.org/cabal-install/_darcs/patches/20080220110637-adfee-…

1 0

[Hackage] #220: detect inconsistent package dependencies
by Hackage 19 Feb '08

19 Feb '08

#220: detect inconsistent package dependencies -----------------------------+---------------------------------------------- Reporter: duncan | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.2.3.0 Severity: normal | Keywords: Difficulty: hard (< 1 day) | Ghcversion: 6.8.2 Platform: | -----------------------------+---------------------------------------------- Now that packages are more fine grained and upgradeable we're commonly getting situations where we build a package that uses two other packages that were built against different versions of another common package. The most common example in the wild at the moment is people installing `bytestring-0.9.0.4` in addition to the `bytestring-0.9.0.1` that came with ghc-6.8.2 and then half their packages are built against one version and half against the other and when they try to use packages built against different versions we get a type error about `bytestring-0.9.0.1:Data.ByteString.ByteString` not being the same as `bytestring-0.9.0.4:Data.ByteString.ByteString`. Cabal could and should detect this situation, and `cabal-install` should plan around it in its dependency resolution algorithm. However in both cases we require the dependency information of the existing installed packages. See http://hackage.haskell.org/trac/ghc/ticket/1839 The simplest thing is to get the full `InstalledPackageInfo` for all the packages in the package databases. From that we can find all the dependencies. When we do find this situation it is not guaranteed to cause a compiler error, it's just rather likely. So it's not obvious if Cabal should warn or error. `cabal-install` could try to fix up inconsistencies but in general only by re-installing existing packages against different versions of their dependencies. The longer term solution is to allow installing multiple instances of the same versions of a package built against different versions of its dependencies. This is the functional Nix approach however it would probably also require support from ghc. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/220> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

3 5

patch applied (cabal): Fix haddock markup
by Duncan Coutts 19 Feb '08

19 Feb '08

Tue Feb 19 05:25:43 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Fix haddock markup M ./Distribution/Simple/InstalledPackageIndex.hs -1 +1 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080219132543-adfee-b58460ca…

1 0

patch applied (cabal): Use the InstalledPackageIndex rather than calling ghc-pkg in Haddock module
by Duncan Coutts 19 Feb '08

19 Feb '08

Tue Feb 19 04:50:50 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Use the InstalledPackageIndex rather than calling ghc-pkg in Haddock module Previously we made two calls to ghc-pkg per-dependent package which starts to get very slow once you have 100's of installed packages and the package you're building depends on several of them. Now we use the cached information about the installed packages. Also refactored the code to generate the haddock package flags so we can export it and use it elsewhere more easily. M ./Distribution/Simple/Haddock.hs -47 +57 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080219125050-adfee-6308f007…

1 0

patch applied (cabal): Add the InstalledPackageIndex to the LocalBuildInfo
by Duncan Coutts 19 Feb '08

19 Feb '08

Tue Feb 19 04:49:32 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Add the InstalledPackageIndex to the LocalBuildInfo So now all the info about installed packages is available to all the verious build phases. M ./Distribution/Simple/Configure.hs +1 M ./Distribution/Simple/LocalBuildInfo.hs +3 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080219124932-adfee-060b3f72…

1 0

patch applied (cabal): Detect broken and inconsistent package deps
by Duncan Coutts 19 Feb '08

19 Feb '08

Mon Feb 18 16:01:39 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Detect broken and inconsistent package deps We now check for packages that are broken due to their dependencies having been unregistered. We fail and print a fairly sensible message in this case. We also check for inconsistent dependencies and give a warning saying which packages are depending on inconsistent versions of a third. This is a warning not an error because it does not always lead to failure. Hopefully it'll help people who are otherwise just running into random compile errors. This fixes ticket #220. M ./Distribution/Simple/Configure.hs -2 +26 M ./Distribution/Simple/InstalledPackageIndex.hs -2 +86 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080219000139-adfee-d134fd30…

1 0

patch applied (cabal): Save horazontal space in the --help output by omitting options to short flags
by Duncan Coutts 19 Feb '08

19 Feb '08

Mon Feb 18 15:57:44 PST 2008 Duncan Coutts <duncan(a)haskell.org> * Save horazontal space in the --help output by omitting options to short flags So instead of "-f FLAGS --flags=FLAGS" we get just "-f --flags=FLAGS" This makes rather better use of 80 cols and means the flag descriptsion are not squeesed into such a narrow column. M ./Distribution/GetOpt.hs -2 +2 M ./Distribution/Simple/Command.hs -1 +4 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080218235744-adfee-115ac0a7…

1 0

Summer of Code?
by Isaac Dupree 19 Feb '08

19 Feb '08

hi guys, does any of you have ideas of how to put me to work Cabal hacking for Haskell.org Summer of Code (or to apply for that highly contested position anyway?). I feel like there may be a web page somewhere that lists Cabal project ideas already, that I just haven't run into, in which case I'd be happy to be pointed to it! sorry for perpetuating the Google invasion, thanks for listening, Isaac

3 3

Repository field
by Henning Thielemann 18 Feb '08

18 Feb '08

What about a Repository field which indicates where the (darcs) repository of the project is located. Sometimes I abuse the Homepage field for this, but I feel that's not the right way and sometimes there are both a homepage and a repository located elsewhere.

2 1