On Fri, 2008-10-03 at 09:55 +0100, Simon Marlow wrote:
Duncan Coutts wrote:
I propose two solutions:
* Fix the dependency resolver * Add support in Cabal and Hackage for suggested version constraints
Simon PJ just came up with a suggestion for the second part. The idea is this:
If we see a dependency like "base >= 3" with no upper limit, we should satisfy it with base-3 in preference to base-4, on the grounds that the package is much more likely to build with base-3. This seems to be a solution that works without any magic shims or "preference files" or anything else.
The suggested version thing really turns out to be the same as saying we should satisfy base >= 3 using base-3 rather than base-4. We want that general mechanism anyway. So I think it's actually more general. We don't need to tell the resolver about base specially, it just extends an already existing notion of soft version preferences. The current resolver allows for soft preferences on the installed state, this just extends that to a general version preference. We want it anyway to better manage transitions like QC1 -> 2 or Parsec 2 -> 3.
Perhaps we could even go as far as saying "base >= 3.0" is equivalent to "base == 3.0.*". i.e. if you don't supply an upper bound, then we'll give you a conservative one. I wonder how much stuff would break if we did that.
The biggest problem is really just that the resolver has to deal with two instances of the same package in its solution. It was designed from the beginning with the assumption that it was accumulating version constraints per-package name (and that all constraints on a package version should be simultaneously satisfiable). We should however have packages declare if they have opted into the package versioning policy. Base would be one of them. We could then warn users when they are using bad version ranges in dependencies on such packages. It'd have to be a field in the .cabal file. Any suggestions for a good name? package-version-policy: Yarr! Duncan