[Haskell-cafe] Re: Proposal: register a package as
providingseveral API versions
Claus Reinke
claus.reinke at talk21.com
Tue Oct 16 11:41:11 EDT 2007
>> 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
More information about the Libraries
mailing list