Ticket #224 (closed enhancement: fixed)

Opened 10 months ago

Last modified 8 months ago

allow specifying package version constraints to configure

Reported by: duncan Assigned to:
Priority: normal Milestone: Cabal-1.4
Component: Cabal library Version: 1.2.3.0
Severity: normal Keywords:
Cc: Difficulty: normal
GHC Version: 6.8.2 Platform:

Description

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.

Change History

01/30/08 14:51:44 changed by igloo

The flag is doing the same job as the build-depends field, so --build-depends="bytestring == 0.9.0.1" makes sense to me.

01/31/08 03:12:55 changed by duncan

Hmm, it's not quite the same since you cannot add extra dependencies. Perhaps that's obvious enough though.

04/20/08 12:28:26 changed by duncan

  • status changed from new to closed.
  • resolution set to fixed.

Fixed: 

Sun Apr 13 14:18:07 BST 2008  Thomas Schilling <nominolo@gmail.com>
  * Change dependency resolution algorithm.
  
  There were two reasons to do this.  Firstly, this formulation makes it
  easier to add the --constraint command line flag that adds additional
  constraints on the packages that should be used.
  
  Secondly, with the orgininal algorithm it was possible to satisfy the
  constraint "foo < 1, foo > 2" if we had two versions of package "foo"
  which each satisfy one constraint.  This patch fixes this by requiring
  the same package to satisfy both constraints (which of course is
  impossible in this case).

Sun Apr 13 19:26:59 BST 2008  Thomas Schilling <nominolo@gmail.com>
  * Fix #224.  We do not yet warn if the user specified a dependency that
  did not occur in the package (it is just silently ignored.)