planning for ghc-6.10.1 and hackage

Claus Reinke claus.reinke at
Fri Oct 3 09:27:37 EDT 2008

> 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.

That sounds reasonable. 
> 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.

All open-ended dependencies are lies.. Well, actually they are optimistic
approximations (some programs will work with base 3 or base 4), and 
closed dependency ranges are pessimistic approximations (few programs 
need all of base 3). The problem is that there is no definite interface spec.

At the moment, precise package versions are the only thing that Cabal
knows about, on the understanding that package+version names (but
not details) an API, and that the real API is some unidentified subset 
of the named API. In light of this, I've been wondering whether the 
complete list of precise package versions should really be part of the 
.cabal file:

- they are little more than hints: I guess that a specific list of package+version
    names identifies a superset of the API my package needs, and if that
    guess turns out to be correct, I leave it in the .cabal file as the closest
    thing to an import API spec that Cabal allows me to write.

- they can be inaccurate both upwards and downwards: my package
    rarely needs all of the import API named by the build-depends, and 
    I'd often be happy if the import API for my package would be
    supplied by some other combination of packages (eg, base-4 + syb
    instead of base-3).

- having precise build-depends means augmenting the package tarballs
    again and again, after testing with newer dependency versions.

Wouldn't it make sense to keep only the initial hint in the .cabal file
("this is the precise combination of packages+versions that my package 
  did build with"), and to let Cabal or Ghc or other tools figure out
additional combinations that also allow the package to build successfully?

These combinations could be tool-generated into a .cabal-configurations
file, which could be stored outside the package tarball, and augmented
whenever new dependency versions come out. Downloading the package
and its successful configuration record would allow cabal-install to pick
a combination that best matches locally installed packages. If a package
doesn't have a successful configuration record, cabal-install can either
try to generate one from the local packages, or insist on downloading the
original configuration. If the former, cabal-install ought to report that
back to hackage, to save itself work on the next installation.

In any case, you wouldn't need to update all hackage package tarballs to
add new dependency version numbers (just their .cabal-configurations
records), and you could do that incrementally, when new dependency
versions come out, and only once per package (instead of everytime
someone tries to install it). 

Does that sound plausible?

More information about the Glasgow-haskell-users mailing list