April 2012 - cabal-devel

[Hackage] #925: Unused constraints result in "no available version"
by Hackage 07 Apr '12

07 Apr '12

#925: Unused constraints result in "no available version" ----------------------------+----------------------------------------------- Reporter: snoyberg | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: Cabal library | Version: 1.10.2.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- When testing out my recently released cabal nirvana[1], Greg Weber pointed out than when building a package that does not use all of the constraints in the Nirvana file, you get a message such as: cabal: There is no available version of authenticate that satisfies ==1.0.0.1 I confirmed that this happens with command-line constraints as well. A simple test case is to go into a non-Yesod project and run: cabal install --constraint "yesod >= 0.10" Unfortunately, this prevents nirvana from being of any use at all, which was our best shot at avoiding dependency hell. [1] http://hackage.haskell.org/package/cabal-nirvana -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/925> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5

Re: [Hackage] #623: when a package is already installed, print the version as well
by Hackage 07 Apr '12

07 Apr '12

#623: when a package is already installed, print the version as well ---------------------------------+------------------------------------------ Reporter: guest | Owner: Type: enhancement | Status: closed Priority: normal | Milestone: cabal-install-0.14 Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: very easy (<1 hour) Ghcversion: | Platform: ---------------------------------+------------------------------------------ Changes (by kosmikus): * status: new => closed * resolution: => fixed Comment: The message is: {{{ $ cabal install multirec Resolving dependencies... All the requested packages are already installed: multirec-0.7.1 Use --reinstall if you want to reinstall anyway. }}} The patch is: {{{ Sat Apr 7 11:28:29 CEST 2012 Andres Loeh <andres(a)well-typed.com> * for empty install plans, print the packages that are installed This is a fix for #623. If we ask to install a package without --reinstall that's already there, then we'll show the package and its version in the warning message and suggest the use of the --reinstall flag. }}} Hopefully done, closing. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/623#comment:4> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #382: 'cabal ghci' mode
by Hackage 05 Apr '12

05 Apr '12

#382: 'cabal ghci' mode ---------------------------------+------------------------------------------ Reporter: guest | Owner: duncan Type: enhancement | Status: new Priority: normal | Milestone: cabal-install-0.16 Component: cabal-install tool | Version: Severity: major | Keywords: Difficulty: normal | Ghcversion: 6.8.2 Platform: | ---------------------------------+------------------------------------------ Changes (by duncan): * owner: => duncan Comment: Half the patches now merged. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/382#comment:16> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #937: cabal-install cannot pass package ids to the build process
by Hackage 05 Apr '12

05 Apr '12

#937: cabal-install cannot pass package ids to the build process ----------------------------+----------------------------------------------- Reporter: kosmikus | Owner: Type: defect | Status: new Priority: normal | Milestone: Cabal-1.16 Component: Cabal library | Version: 1.14.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------+----------------------------------------------- The solver determines an install plan that fixes package ids of installed packages. However, the Setup interface currently does not allow us to specify package ids once we start building; we can only fix the versions. This can lead to problems in situations where multiple instances of the same package version are installed on a system, and the install plan selects one, but we cannot uniquely communicate that to the builder. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/937> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 2

Re: [Hackage] #470: identify and exclude broken or unusable packages when constructing and merging package dbs
by Hackage 05 Apr '12

05 Apr '12

#470: identify and exclude broken or unusable packages when constructing and merging package dbs ---------------------------------+------------------------------------------ Reporter: guest | Owner: kosmikus Type: defect | Status: closed Priority: normal | Milestone: cabal-install-0.14 Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Resolution: fixed Keywords: solver | Difficulty: hard (< 1 day) Ghcversion: | Platform: ---------------------------------+------------------------------------------ Changes (by kosmikus): * status: new => closed * resolution: => fixed Comment: I'm closing this one, as the original problems, the error message and the handling of broken packages, are fixed. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/470#comment:7> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #470: identify and exclude broken or unusable packages when constructing and merging package dbs
by Hackage 05 Apr '12

05 Apr '12

#470: identify and exclude broken or unusable packages when constructing and merging package dbs ---------------------------------+------------------------------------------ Reporter: guest | Owner: kosmikus Type: defect | Status: new Priority: normal | Milestone: cabal-install-0.14 Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: solver Difficulty: hard (< 1 day) | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Comment(by kosmikus): Also see #937. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/470#comment:6> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

Re: [Hackage] #470: identify and exclude broken or unusable packages when constructing and merging package dbs
by Hackage 05 Apr '12

05 Apr '12

#470: identify and exclude broken or unusable packages when constructing and merging package dbs ---------------------------------+------------------------------------------ Reporter: guest | Owner: kosmikus Type: defect | Status: new Priority: normal | Milestone: cabal-install-0.14 Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: solver Difficulty: hard (< 1 day) | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Comment(by kosmikus): This turned out to be trickier than I first expected. The problem is that the underlying shadowing is an incredibly subtle thing. Here are a few facts: * The new modular solver produces a better error message. * Unlike the old (topdown) solver, the modular solver will just consider multiple installed instances of a package to all be available, even if they have the same version. * It's possible to install packages with cabal-install that ghc/ghci will not be able to load with a simple -package flag, because GHC applies shadowing in such a situation. However, explicitly selecting the packages with -package-id should help in such a case. * It's possible for Cabal to fail at build time because currently, the interface between cabal-install and the build process is suboptimal. We only pass version constraints to the individual package builds, not the exact package identities, even if we have them. * I've added functionality to the modular solver so that it can, if desired, apply shadowing itself, by disabling packages from the installed package index. * Broken packages with missing dependencies should be disabled now in the solver. * Applying shadowing seems like the wrong thing to do, though, and despite the lossy flag passing to the builder, the situations that fail are rare (fewer than would be rejected if shadowing was enabled in the index). So I've disabled shadowing for now. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/470#comment:5> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #928: Modular solver needs support for ghc-6.12's base-wrapping
by Hackage 05 Apr '12

05 Apr '12

#928: Modular solver needs support for ghc-6.12's base-wrapping ---------------------------------+------------------------------------------ Reporter: kosmikus | Owner: kosmikus Type: defect | Status: new Priority: normal | Milestone: cabal-install-0.14 Component: cabal-install tool | Version: HEAD Severity: normal | Keywords: solver Difficulty: normal | Ghcversion: 6.12.3 Platform: | ---------------------------------+------------------------------------------ In ghc-6.12, we had the situation that base-3 was a wrapper around base-4. The modular solver can currently not handle that situation, thereby making it mostly useless when used with ghc-6.12. For later ghc versions, this no longer occurs, thus isn't an issue. This is one reason why the modular solver currently is not the default. Options: * Add a hack to the modular solver to deal with it, much like it is done in the topdown solver. * Make the default solver being used dependent on the version of ghc (but that might be confusing). -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/928> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 1

Re: [Hackage] #405: cabal-install finds non-existent conflict due to picking base 3
by Hackage 05 Apr '12

05 Apr '12

#405: cabal-install finds non-existent conflict due to picking base 3 ---------------------------------+------------------------------------------ Reporter: dreixel | Owner: kosmikus Type: defect | Status: new Priority: low | Milestone: cabal-install-0.16 Component: cabal-install tool | Version: 1.6.0.1 Severity: normal | Keywords: solver Difficulty: hard (< 1 day) | Ghcversion: 6.10.1 Platform: | ---------------------------------+------------------------------------------ Changes (by kosmikus): * priority: normal => low * milestone: cabal-install-0.14 => cabal-install-0.16 Comment: I'll not fix this for 0.14 after all, but this situation should now be relatively rare. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/405#comment:7> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 0

[Hackage] #936: Add Haddock-Options field to Cabal package description
by Hackage 03 Apr '12

03 Apr '12

#936: Add Haddock-Options field to Cabal package description ----------------------------------+----------------------------------------- Reporter: guest | Owner: Type: enhancement | Status: new Priority: normal | Milestone: Cabal-1.16 Component: Cabal specification | Version: 1.10.2.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ----------------------------------+----------------------------------------- Currently when running 'runhaskell Setup haddock' I can pass options to Haddock with the --haddock-option and --haddock-options option. I would like to add some options in a Cabal description file analogously to the GHC-Options fields and others. -- Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/936> Hackage <http://haskell.org/cabal/> Hackage: Cabal and related projects

1 5