[Hackage] #224: allow specifying package version constraints to configure

Hackage trac at galois.com
Tue Jan 29 13:21:03 EST 2008


#224: allow specifying package version constraints to configure
----------------------------+-----------------------------------------------
  Reporter:  duncan         |        Owner:           
      Type:  enhancement    |       Status:  new      
  Priority:  normal         |    Milestone:  Cabal-1.4
 Component:  Cabal library  |      Version:  1.2.3.0  
  Severity:  normal         |     Keywords:           
Difficulty:  normal         |   Ghcversion:  6.8.2    
  Platform:                 |  
----------------------------+-----------------------------------------------
 Currently, configure considers the version constraints from the `build-
 depends` of the `.cabal` file. Of the available packages that satisfy
 those constraints it picks the highest version.

 This is not always what we want. The user might want to pick a specific
 version of a dependency (eg for testing or to avoid a known dud).

 cabal-install certainly wants to specify package versions exactly because
 it does its own dependency resolution and it may well end up not picking
 the latest version of an available dependency, eg to ensure consistent
 versions of a dependent package (see #220).

 So the dependencies would be specified just as in `build-depends`, for
 example:

 {{{
 cabal configure --constraint="bytestring == 0.9.0.1"
 }}}

 (suggestions for a better flag name welcome)

 However it must only be for dependencies that the package actually depends
 on. It should be an error to specify constraints on packages that could
 never be used by the package we are configuring. The fact that package
 dependencies can be conditional complicates this slightly. To be precise,
 we could say that if the package name is not mentioned in the flattened
 package description then it is an error. If the package named in the
 constraint happens merely not be use in the selected configuration then it
 is not an error and the constraint is discarded.

 So an external package manager (like cabal-install) can control exactly
 how a package will be configured by setting all the use flags and
 precisely constraining all the dependencies.

-- 
Ticket URL: <http://hackage.haskell.org/trac/hackage/ticket/224>
Hackage <http://haskell.org/cabal/>
Hackage: Cabal and related projects


More information about the cabal-devel mailing list