- cabal-devel - Haskell.org

patch applied (cabal-branches/cabal-1.4): Add PackageIndex.delete
by Duncan Coutts 07 May '08

07 May '08

Tue May 6 06:16:03 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Add PackageIndex.delete We occasionally need to remove packages from an index eg to restrict the choices of a dependency resolver. M ./Distribution/Simple/PackageIndex.hs -1 +14 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/2008050613…

1 0

patch applied (cabal-branches/cabal-1.4): Remove a test for the specific kind of exception for nhc98 compatibility
by Duncan Coutts 07 May '08

07 May '08

Tue May 6 03:28:04 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Remove a test for the specific kind of exception for nhc98 compatibility This was the check for ghc-pkg failing. We cannot check for the exception being an ExitException since that assumes ghc's representation of the Exception type, whereas nhc98 defines: type Exception = IOError M ./Distribution/Simple/GHC.hs -6 +2 View patch online: http://darcs.haskell.org/cabal-branches/cabal-1.4/_darcs/patches/2008050610…

1 0

patch applied (cabal): Add PackageIndex.reverseDependencyClosure
by Duncan Coutts 07 May '08

07 May '08

Tue May 6 16:49:02 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Add PackageIndex.reverseDependencyClosure It's similar to dependencyClosure but looks at reverse dependencies. For example it's useful to find all packages that depend on broken packages and are thus themselves broken. M ./Distribution/Simple/PackageIndex.hs -1 +22 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080506234902-adfee-09deee71…

1 0

patch applied (cabal): Improve style and performance of PackageIndex.dependencyClosure
by Duncan Coutts 07 May '08

07 May '08

Tue May 6 16:44:47 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Improve style and performance of PackageIndex.dependencyClosure Keep the completed set as another PackageIndex rather than a list. We want to return an index at the end anyway and in the mean time we want to do lots of lookups to see if we've visited previously. M ./Distribution/Simple/PackageIndex.hs -12 +10 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080506234447-adfee-60242561…

1 0

patch applied (cabal): Add PackageIndex.dependencyGraph that builds a Graph
by Duncan Coutts 07 May '08

07 May '08

Tue May 6 16:43:26 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Add PackageIndex.dependencyGraph that builds a Graph Useful for some more tricky queries. M ./Distribution/Simple/PackageIndex.hs +34 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080506234326-adfee-f3e9bb77…

1 0

patch applied (cabal): Add PackageIndex.delete
by Duncan Coutts 07 May '08

07 May '08

Tue May 6 06:16:03 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Add PackageIndex.delete We occasionally need to remove packages from an index eg to restrict the choices of a dependency resolver. M ./Distribution/Simple/PackageIndex.hs -1 +14 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080506131603-adfee-ea635718…

1 0

A (in)sane idea about (never) breaking Setup.(l)hs files again
by Marc Weber 06 May '08

06 May '08

module Main where import Distribution.Simple72 main = mainWithHooks ( .... ) Could be one way to achieve this goal in most simpler API changes (up to rewriting the whole core using more monads as all information is pased) How could it work? The Cabal distribution ships with src/Distribution/Simple1.hs: import Distribution.Simple2 import Types1 import Types2 -- wrapper for the new Simple2 api exporting API1 [..] src/Distribution/Simple2.hs: import Distribution.Simple3 [..] I guess you get the idea. This way API v1 uses API v2 using API v3 .. using API vlatest. There is another case: What happens if the Setup.hs fits a newer cabal version (2) but you have only (1) installed? You could get an api wrapper mapping API v2 back to API1 you have. And the cool thing: Adding this wrapper could be automated because reading the Distribution.SimpleX versions is simple.. Propably the best way handling this case is: Update your Cabal version anyway :) It's a nice documentation about how to upgrade your Setup files as well.. because looking at the "dummy" files only calling the other API versions should give you all you need. I'm not sure about how everyone would like having Distribution/Simple{1,2,3,4,5,6,7,8,9,...200}.hs files But thinking about how many cabal using people could benefit from this easy to accomplish up and downgrading it might be worth it. Some small changes (removing the Bool arg in runTests) and the flagVerbose change would be really trivial then without having to read lots of Cabal code I think Cabal devs know best how often this could have helped people ? It would make the life of all package mantainers a lot easier.. and of those devs having SetupX{1,2,3}.hs flying around. You can't forget about all trouble.. just about some incompatibilies. Any thoughts? Marc Weber

1 0

cabal-install uninstall ?
by Benedikt Huber 06 May '08

06 May '08

Hello, I appreciate ongoing work with cabal-install. I've tried the latest darcs version on a clean fresh ghc, and it worked fine. I wonder however, if there is any support (planned) for removing outdated packages. For example, when updating bytestring, I ended up with both xhtml-3000.0.2.1 and xhtml-3000.0.2.2 installed. Is there a something like a receipt, listing the files belonging to the installation of a package ? If there were such a thing (like copy --verbose, but machine readable), uninstalling a list of outdated packages would at least be possible. I wouldn't want cabal to remove outdated packages automatically, but some support for listing and removing them seems quite important to me. Oh, and it would be nice if config fields like 'global-prefix' are mentioned in the README. In the long term, in which way should cabal-install interact with package management tools like macports ? Is it supposed to be a replacement, an alternative or a complement ? I thought about writing something similar as cabal-rpm for macports, but it seems better to have cabal-install handle dependency resolution and installation. Injecting a package into the pm's database after installing is imho the nicest solution. Does this make sense ? Thanks, Benedikt

3 2

patch applied (cabal): Remove a test for the specific kind of exception for nhc98 compatibility
by Duncan Coutts 06 May '08

06 May '08

Tue May 6 03:28:04 PDT 2008 Duncan Coutts <duncan(a)haskell.org> * Remove a test for the specific kind of exception for nhc98 compatibility This was the check for ghc-pkg failing. We cannot check for the exception being an ExitException since that assumes ghc's representation of the Exception type, whereas nhc98 defines: type Exception = IOError M ./Distribution/Simple/GHC.hs -6 +2 View patch online: http://darcs.haskell.org/cabal/_darcs/patches/20080506102804-adfee-4c87c721…

1 0

darcs patch: Add new utils, duplicates, duplicatesBy ... (and 4 more)
by Duncan Coutts 05 May '08

05 May '08

All, If you want to play with the new dependency resolver stuff then here is a bunch of patches. Dependency resolvers are now expected to produce a valid InstallPlan. There is new error checking code to tell you all the ways in which the InstallPlan your dep resolver produced, is invalid. The current dep resolver can sometimes produce valid install plans but can easily be persuaded into making invalid ones, especially if you have many broken packages installed. So there's still some work to be done to make the dep resolvers more pluggable and to try to patch up the current dep resolver a bit. Duncan Sun May 4 20:45:30 BST 2008 Duncan Coutts <duncan(a)haskell.org> * Add new utils, duplicates, duplicatesBy and mergeBy Sun May 4 21:17:42 BST 2008 Duncan Coutts <duncan(a)haskell.org> * Use the mergeBy from the Utils module Sun May 4 21:18:57 BST 2008 Duncan Coutts <duncan(a)haskell.org> * Improve InstallPlan error checking and reporting Instead of just reporting that a plan is invalid, produce a detailed list of reasons why it is invalid. This should be useful for people debugging dependency resolvers. Also rename the complete property to closed, since the property is about the set being closed under the dependency relation. Also re-use the PackageIndex functions for checking the validity conditions rather than re-implementing the checks locally. Mon May 5 10:05:13 BST 2008 Duncan Coutts <duncan(a)haskell.org> * Packages are only invalid if they have more than zero problems. Mon May 5 10:17:43 BST 2008 Duncan Coutts <duncan(a)haskell.org> * Switch from DepGraph to InstallPlan The dependency resolver has had to be extended in a slightly hacky way to gather the extra information needed by an install plan. In particular it requires the flags to use to configure each package, the actual versions of dependencies to use and all of the installed packages and their closure of dependencies. However the current resolver is fairly naive and so can be easily persuaded into producing an invalid install plan, in which case you'll get a detailed list of reasons as to why it is invalid.

1 0