Long-term success of Cabal configurations?

[Isaac Dupree]

Stefan O'Rear wrote:
> On Wed, Aug 15, 2007 at 02:34:22PM +0100, Duncan Coutts wrote:
>> Cabal configurations should make this situation better. Cabal does
>> support ghc back to 6.2.2 and with a suitable .cabal file it should be
>> possible to make most progs work with a range of compiler versions.
> 
> I'm not so sure.  Cabal configurations look like they will fix the
> problem, but given a few years every .cabal file out there will look
> like a pre-autoconf C program's config.h, just a huge tangle of feature
> tests and conditional module usages...
> 
> 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* }

Do we need to cater to situations in which Cabal, or old packages' 
.cabal files, aren't upgradable? I'd guess not, because then why would 
you be able to install newer packages that need any of this, either? 
Assuming we don't...

New versions should depend on whatever the newest name for the package 
is (e.g. "bytestring").  There are old names like "base" and "fps" that 
provide older versions of the same thing.  Somehow (update their cabal 
files? Bake knowledge into a centralized place like a part of Cabal?) 
these names should be translated so that (requiring bytestring in GHC 
6.6) pulls in (base) instead...... too bad for programs that need a 
newer version of ByteString perhaps? Or, a "bytestring" might be 
installable...

> 
> ... which unfortunately doesn't handle splits (FiniteMap etc) anywhere
> near as well.
> 
> Why have package names, again?  It seems using modules names instead
> would completely fix this problem, and with the small restriction that a
> module name, once used, is not reused for something incompatible, solves
> the versioning problem as well.

1. upgrades make incompatibility anyway, sometimes
2. sometimes it is (or should be? or is likely to be, sometime in 
future?) decided that a module change is for the better
3. module Main... (divergent leaves are not a problem as long as it 
remains a tree, not generally an acyclic graph, of dependencies; module 
Main dep. on (A which dep. on C{-1-}) and (B which dep. on C{-2-}) won't 
work in ghc<6.6 and I don't know about other Haskell implementations)

Module names allow you to have sort-of-broken packages and libraries 
without them interfering with normal package usage.  Package and 
dependency renaming can be performed without any change to Haskell 
source code, which is viewed as a desirable partitioning.

Isaac