brainstorming ways to stabalize Cabal interface?

[Duncan Coutts]

On Thu, 2006-01-19 at 10:50 +0000, Simon Marlow wrote:

> In the past I suggested 2, but I think I'd be equally (or perhaps more) 
> happy with 3.  To compare 2 and 3:
> 
>    - it seems a bit strange to use ETC just for Cabal, but I don't
>      support doing it for everything (it's too heavyweight a solution)
> 
>    - 3 requires us to provide multiple versions of the Cabal package,
>      rather than one version that supports multiple interfaces.  This
>      is perhaps less work for the Cabal developers (keeping the old
>      interfaces working is easier, we just compile the old code), but
>      it means more bloat.

Though people only need the versions that are needed by the packages
they install. These can be dragged in on demand by distro package
managers. For the manual case the "cabal" wrapper program tells the user
what they need to install.

>    - 3 lets us do away with Setup.hs when it is just boilerplate

>    - 3 means an upheaval in the end-user's view of Cabal.  They have to
>      run "cabal build" (or whatever) instead of "runhaskell Setup.hs
>      build"
> 
>    - the wrapper program can transparently compile Setup.hs instead of
>      interpreting it each time, which is a lot faster

Yeah, the Gentoo Cabal system does this.

> I think I'm coming down on the side of Duncan's suggestion, despite the 
> fact that it's a pretty big interface change.  We could migrate slowly 
> by making 'runhaskell Setup.hs' emit a warning for the time being.

We've had a few interface changes and inconsistencies before and
generally in practise:
      * At one time people were supposed to use ./Setup.lhs and the
        Setup.lhs file was supposed to invoke runhaskell via the #!
        method.
      * Some packages supply Setup.hs rather than Setup.lhs.
      * Some packages supply no Setup.(l)hs at all.
      * Some instructions suggest to use runghc Setup.lhs rather than
        runhaskell Setup.lhs on the basis that one is more reliable.

By having package developers and users using the same "cabal" script
should help reduce these and other inconsistencies. For example some
packages rely on optional packages for their Setup.lhs script itself!
For example a Setup.lhs file that uses modules from the FilePath
package. This is something that happens to work on the developers
machine but will not work on the users machine if the user does not have
the package. This is true even if the developer lists the FilePath
package in their .cabal file, since we can't run the setup program to
know that we need the FilePath package! A "cabal" wrapper program could
stop the developer from making that kind of mistake by compiling the
Setup.lhs using --ignore-all-packages (or whatever the ghc flag is) so
that it does not depend on any packages other that base and haskell98.

One other change that would be good to support this is to specify in a
new field in the .cabal file the version of the Cabal API that is
required. It can sort-of be done at the moment by using the
build-depends, but this will cause the resulting library to depend on
Cabal.

If we take this route, I think it'd be good to address John Meacham's
query about who provides cabal and the wrapper script/prog. Is it the
compilers or something separate? For example, John asked what happens if
runhaskell points at jhc (assuming jhc can even provide such a thing)
will that work if the user is trying to install a package for ghc?
Perhaps this is something that the script can sort out. Perhaps it
should use the implementation being targeted to compile/interpret the
Setup.(l)hs file.

Duncan