the idea was for the cabal file to specify a single provided api,
but to register that as sufficient for a list of dependency numbers.
so the package would implement the latest api, but could be used
by clients expecting either the old or the new api.
I don't see how that could work. If the old API is compatible with the new
API, then they might as well have the same version number, so you don't
need this. The only way that two APIs can be completely compatible is if
they are identical.
if that is your definition of compatible, you can never throw any
packages away, because they can never be subsumed by newer
versions of themself. alternatively, it would require perpetual
updates of dependencies in package descriptions, which we'd
like to avoid, right?
a few examples, of the top of my head:
- consider the base split in reverse: if functionality is only repackaged,
the merged base would also provide for the previously separate
sub-package apis (that suggests a separate 'provides:' field, though,
as merely listing version numbers wouldn't be sufficient)
- consider the base split itself: if there was a way for the base split
authors to tell cabal that the collection of smaller packages can
provide for clients of the the old big base, those clients would
not run into trouble when the old big base is removed
- consider adding a new monad transformer to a monad transformer
library, or a new regex variant to a regex library - surely the new
package version can still provide for clients of the old version
- consider various packages providing different implementations
of an api, say edison's - surely any of the implementations will
do for clients who depend only on the api, not on specifics
the reason this could work when updating packages is that packages
written against the old api were not aware of the new features in the
new api. when compiling a package against a dependency providing
multiple versions, there should be a warning if the client does not
refer to the newest version - but it would still build, and there'd be
a clear hint as to what needs to be changed.
A client of an API can be tolerant to certain changes in the API, but that
is something that the client knows about, not the provider. e.g. if the
client knows that they use explicit import lists everywhere, then they can
be tolerant of additions to the API, and can specify that in the dependency.
that is the very issue i'd like to see reversed.
you're right the first time round: when the client is first written,
it is the client's responsibility to specify a useable dependency
version; but keeping the responsibility this way round causes
nothing but trouble after the client has been released, if its
dependencies develop faster than the client (in the current
case, if a major change in base shakes the foundation all
other packages were built on; a more typical example would
be: someone writes a useful package P, depending on X, Y, Z,
then leaves academia to hack web pages for a living, leaving
users and clients of P frustrated as X, Y, and Z move on).
so, i'd like to see two stages, before and after publishing:
1. author of client package specifies precise dependencies
2. users of client packages can continue using it unchanged
even if its dependencies move on
one way to assure 2 is to keep all old package versions
around forever somewhere (we can't do a whole-web
garbage collection, so we never know when there are
no more pointers).
another way is to allow authors of package dependencies
to take on part of the burden, thereby helping to reduce
breakage and garbage for their clients. so the authors of
mtl-9.0 could note that it still provides all the modules of
earlier versions, so the package manage would only have
to keep the latest version around, and clients of earlier
versions would not notice any breakage.
You'll get a type error - try it. The big change in GHC 6.6 was to allow
this kind of construction to occur safely. P-1:A.L is not the same type as
P-2:A.L, they don't unify.
i did (just before pressing send;-). the message (in 6.6.1) was
of the kind 'A.L Integer' does not match 'A.L Integer'. i see
you've now added both package and version to the error
message - that should reduce the confusion. since package
sources may not be available, this is still not ideal, but i don't
see what to do about that.
claus
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
