I have another concrete proposal to avoid things breaking so often. Let us
steal from something that works: shared library versioning on unixy systems.
indeed!-) there are established workarounds that are needed to
make that system work as it does, so it is a good idea to check
whether cabal has the means to cover those situations.
The above declaratively expresses that libcurl-3.3.0 provides the version 3 API
and the version 2 API.
This is the capability that should be added to Haskell library packages.
Right now a library can only declare a single version number. So if I update
hsFoo from 2.1.1 to 3.0.0 then I cannot express whether or not the version 3 API
is a superset of (backward compatible with) the version 2 API.
Certainly, this is something we want to support. However, there's an
important difference between shared-library linking and Haskell: in
Haskell, a superset of an API is not backwards-compatible, because it has
the potential to cause new name clashes.
yes, one would need to define what it means for one api to be
compatible with another. even so, i think that permitting a single
package to act as a provider for multiple versions of an api is
a necessary feature, even more so if loose dependency specs
like 'base', or 'base >= 1.0' are going to be discouraged.
It could be done using the tricks that Claus just posted and I followed up
on. You'd need a separate package for hsFoo-2 that specifies exactly which
bits of hsFoo-3 are re-exported. Given some Cabal support and a little
extension in GHC, this could be made relatively painless for the library
maintainer.
are those tricks necessary in this specific case? couldn't we
have a list/range of versions in the version: field, and let cabal
handle the details?
aside: what happens if we try to combine two modules M and N
that use the same api A, but provided by two different packages
P1 and P2? say, M was built when P1 was still around, but when
N was built, P2 had replaced P1, still supporting A, but not
necessarily with the same internal representation as used in P1.
claus
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
