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?
Claus
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
