On Thu, Aug 16, 2007 at 09:29:28PM +0200, Thomas Schilling wrote:
On 15 aug 2007, at 20.20, Stefan O'Rear wrote:
I'd much prefer a situation where the (much smaller number of) library authors carry the burden of compatibility; maybe something like
{- in base-2.0's .cabal -}
Provides: fps-1.0 by { Data.ByteString* }
... which unfortunately doesn't handle splits (FiniteMap etc) anywhere near as well.
How far would re-exporting imported modules bring us? This would allow some sort of "virtual" packages (put in quotes, because I don't know how much this reflects the usage of this term in, e.g., Gentoo), which could at least solve package splits quite nicely.
Assume we have base-2.0. Then the .cabal for base-1.0 could look somewhat like:
build-depends: base >= 2.0, filepath, {- ... -} exposed-modules: Data.ByteString*, System.FilePath*, {- ... -}
Hmm, good point. I like it. (I do think it would work much better if Cabal had a better notion of version numbers that includes forward compatibility and suchlike - don't ever satisfy a 1.0.0 request with 2.x.y, etc)...
I really don't like hacks with configurations like
if flag(small_base) { build-depends: base >= 2.0, filepath >= 1.0, ... } else { build-depenhs: base >= 1.0 && base < 2.0 }
since they have to be put in _every_ .cabal file.
And fragile, too - when someone tries to build on GHC 6.4 for the first time, that misspelled field will cause major headaches :) Stefan