[Hackage] #925: Unused constraints result in "no available version"
#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
#925: Unused constraints result in "no available version" ---------------------------------+------------------------------------------ Reporter: snoyberg | Owner: Type: defect | Status: new Priority: normal | Milestone: Component: cabal-install tool | Version: 1.10.2.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Changes (by snoyberg): * component: Cabal library => cabal-install tool -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/925#comment:1 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#925: More flexible constraints, specified via local preferences file ---------------------------------+------------------------------------------ Reporter: snoyberg | Owner: Type: enhancement | Status: new Priority: normal | Milestone: cabal-install-0.14 Component: cabal-install tool | Version: 1.10.2.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Changes (by kosmikus): * type: defect => enhancement * milestone: => cabal-install-0.14 Comment: I've changed your bug into an enhancement request. What you're describing is intended behaviour. A constraint passed on the command line acts the same as a constraint put in the build-depends of a package, i.e., it not only restricts the range of versions, but also causes the package to actually be installed. The closest to what you want that currently exists is --preference, and it should actually be sufficient in most cases. A --preference constraint does not prevent excluded versions from selected at all, but it will first try all preferred versions. I appreciate the attempt you make with cabal-nirvana, but I don't like that it works by actually changing the downloaded files. Cabal already supports a global preferences file that's downloaded from Hackage. It should probably support local files with preferences, too. That would be relatively easy to change. So there are two possible enhancements in this issue: * introduce a way to easily specify a large number of local preferences, * next to constraints introduced by --preference and --constraint The mail http://www.mail-archive.com/haskell-cafe@haskell.org/msg96962.html as well as the surrounding thread are also somewhat related. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/925#comment:2 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#925: More flexible constraints, specified via local preferences file ---------------------------------+------------------------------------------ Reporter: snoyberg | Owner: Type: enhancement | Status: new Priority: normal | Milestone: cabal-install-0.14 Component: cabal-install tool | Version: 1.10.2.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Comment(by kosmikus): Also see #380. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/925#comment:3 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#925: More flexible constraints, specified via local preferences file ---------------------------------+------------------------------------------ Reporter: snoyberg | Owner: Type: enhancement | Status: new Priority: normal | Milestone: cabal-install-0.14 Component: cabal-install tool | Version: 1.10.2.0 Severity: normal | Keywords: Difficulty: unknown | Ghcversion: Platform: | ---------------------------------+------------------------------------------ Comment(by kosmikus): I may have misunderstood the intended meaning of the {{{--constraint}}} flag. Investigating. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/925#comment:4 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
#925: Unused constraints result in "no available version" ---------------------------------+------------------------------------------ Reporter: snoyberg | Owner: Type: defect | Status: closed Priority: normal | Milestone: cabal-install-0.14 Component: cabal-install tool | Version: 1.10.2.0 Severity: normal | Resolution: fixed Keywords: | Difficulty: unknown Ghcversion: | Platform: ---------------------------------+------------------------------------------ Changes (by kosmikus): * status: new => closed * type: enhancement => defect * resolution: => fixed Comment: Ok. I think that I have indeed mistakenly assumed that the old behaviour of `--constraint` was intended when it was not. Sorry for that. In the current development repository (and in the upcoming `cabal- install-0.14`), constraints behave as was the assumption in this bug report originally. Saying `--constraint=...` on the command line does *not* introduce a target, it merely constrains the package. So I'll restore the original title and consider this bug as fixed. -- Ticket URL: http://hackage.haskell.org/trac/hackage/ticket/925#comment:5 Hackage http://haskell.org/cabal/ Hackage: Cabal and related projects
participants (1)
-
Hackage