Long-term success of Cabal configurations? (was: Stability vs latest features)

[Stefan O'Rear]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.haskell.org/pipermail/libraries/attachments/20070816/a8704406/attachment.bin