Multi-versioning and compatibility classes.
jason.dusek at gmail.com
Mon Nov 30 14:28:43 EST 2009
I have been looking at the Cabal roadmap (tickets marked for
bottom) and notice that no one has mentioned multi-versioning
or compatibility classes. Maybe these are bad ideas?
Multi-versioning seems highly desirable. Essentially, it
allows us to have the same qualified names be provided by
different packages for different packages. This is desirable
in the case of package versions which really are no longer the
same, like Parsec 2 and Parsec 3; it also allows for the case
where more than one package specifies the same qualified name
because it is obvious (like `Text.JSON` or some such). It
stands to reason that the "package environment" specified in
the `.cabal` file is enough to tell us which package we really
need to use.
However, there are problems, too. Like what if I have one
package that depends on `parsec-220.127.116.11` and another that
depends on `parsec-18.104.22.168`? With multi-versioning, they both
compile fine but then I try to use a parser from one with a
combinator defined in the other: this fails to compile
is not the same as:
So now we need compatibility classes. The first package might
specify a package dependency like:
where we take the `~` to mean "requires something compatible
with". The second package specifies a similar dependency:
Then the maintainer of Parsec specifies that 22.214.171.124 is
compatible with 126.96.36.199 and we can compile the second package,
the one that require 188.8.131.52, with 184.108.40.206 since they are
compatible and that is all it is asking for. Then we try to
use these two packages together and everything works.
More information about the cabal-devel