On 01 February 2006 17:45, Isaac Jones wrote:

"Simon Marlow" writes:

...

On 31 January 2006 21:38, Isaac Jones wrote: (snip)

...

Ahem. Cabal-install.

It doesn't read that field yet, though.

Do you intend cabal-install to be the main interface to Cabal? That's what Duncan was proposing (and others have suggested) - that we deprecate the use of 'runhaskell Setup.lhs' as the interface to Cabal in favour of a program to do the same.

I don't know if cabal-install should be the main interface or not; I think it's worth experimenting with. As far as I know, I'm the only one who's tried it :)

...

Certainly there doesn't seem much point in having *both* cabal-install and another wrapper, so clearly they should be the same thing. I do think this is the way to go, though.

You think we should move away from saying that "setup" is the interface? Would we start distributing cabal-install w/ the compilers, or expect users to install it on their own?

I'm referring to discussion from a couple of weeks ago: http://www.haskell.org//pipermail/libraries/2006-January/004815.html basically, yes, I think Cabal should come with a tool that you run instead of 'runhaskell Setup.hs'. This will actually result in more consistency, because as Duncan pointed out in that thread, there are currently lots of ways to run Setup.hs. The tool can check for the cabal-version field before it does anything, and run the Setup script with the appropriate version of Cabal (or fail if it can't find it). This neatly fixes the problem of changing APIs in Cabal. The command line interface for the tool can be exactly the same as Setup right now. Plus another option to behave like cabal-install, maybe.

The problems with the setup script are mainly: 1) the interface changes (though that is hopefully a short-term problem) 2) we can't count on runhaskell being installed

A better solution might be to work hard on stabalizing the interface. I would like to try to stabalize cabal and move future development into layered tools.

Stabilizing the API and layered tools are both good, but I'm sure we'll want to extend the API in the future. Using a small wrapper program instead of invoking Setup.hs directly ensures we'll be able to do this smoothly in the future, without breaking lots of Setup scripts. I don't think this is that big a deal, it isn't a fundamental design switch, the functionality is still implemented in Haskell and completely customisable by each package, all we're doing is replacing the words 'runhaskell Setup.hs' with 'cabal-setup' (or something). Cheers, Simon