cabal setup scripts (was: Re: building haddock?)

[Isaac Jones]

John Meacham <john at repetae.net> writes:

> On Wed, Feb 01, 2006 at 09:45:27AM -0800, Isaac Jones wrote:
>> > 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 :)
>
> I very strongly feel that 'cabal-install' should be the main interface
> to cabal. having Setup.[l]hs files leads to a lot of headache and
> doesn't gain us anything. (note, I am not saying drop the library, just
> the need for Setup.* scripts)

I do understand your position as you state it, that you think the
Setup scripts cause unnecessary complexity.  I think they serve an
important purpose that I hope I can explain to you.  Maybe you could
capture our two arguments on a wiki page somewhere :)

> we should add a field to the cabal file:
>
> build-style: simple
> build-style: make

I am coming around to a certain amount of what you say.  I'm leaning
toward a scheme something like "if the setup script is there, build it
and use it, otherwise use defaultMain."  Let's call that the "optional
Setup" proposal.  This has always been on the table, BTW, and the
reason that I resist it is because it's much harder to _add_ a
requirement of a setup script than to relax it.

The optional Setup proposal helps us get rid of the difficulty of
compiling the Setup script (for "simple" systems) in exchange for the
difficulty of distributing cabal-install.

In fact, distributing runhaskell would basically have the same effect.

I think that if we drop the requirement for the Setup scripts, then
we'll probably want a build-style field, but I think the values should
probably be "simple" and "setup"; maybe "make" and something to
represent "main=defaultMainWithHooks defaultUserHooks".

> build-style: custom runhaskell Setup.lhs
> build-style: custom runhaskell MyBuild.hs -c %

You lose me here, I feel like this idea gives up most of the pros we
gained by dropping the Setup script.

> This makes the simple cases a whole lot easier and less brittle and
> doesn't lose any functionality.
>
> I would also add
>
> build-prehook:
> build-posthook:
> ...
>
> to the cabal file and have cabal-install just fill in those fields in
> the hook record with the values from the file.

So the build hooks basically all become IO ()?  That's rather
unsatisfying to me as a functional programmer :)

(snip)
> <noise>
>
> there is also a philosophical objection to Setup.hs as well as a practical
> one. turing completeness is a one-way ratchet. once you decide on an
> arbitrary program rather than having a declarative format then you lose
> the ability to write meta-tools that analyze your projects in ways that
> were originally unintended. a program is only good for its one task, you
> can't look inside it, it is a black box. a declarative format can be
> parsed and looked at in new and interesting ways. making things programs
> should always be a last resort. Also, it is kind of passing the buck.
> we avoid thinking about the hard problems by just saying 'write a custom
> Setup.hs' to handle it. Of course, the joke is on us since we are the
> ones using cabal so we are just passing the buck to ourselves. Also, it
> feels a little embarasing that a functional language wouldn't use a
> declarative format by default with a program as a last resort. 
>
> </noise>

While we're talking philosophy maybe I can let you in on the
philosophy behind the Setup script.  One problem with domain-specific
declarative languages like the .cabal file is that they grow into
(ugly) turing complete programming languages.  I would prefer to keep
cabal rather simple (it's already almost too complex, IMO) and yes,
push the complexity into the setup script.  You may see it as passing
the buck, I see it as allowing the end user to program in a beautiful
language for those inevitable turing-tasks.

Cabal can and should leverage abstraction where it appears, such as
preprocessors and Programs (which it can detect and add nice flags
like --with-foo-path= and --with-foo-args=).

You did seem to recognize the necessity for escaping to a
turing-complete language in your build-style: custom proposal.
Indeed, your proposal requires us to bail out to a turing complete
language in exactly the same circumstances as the current situation.


peace,

  isaac