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

[John Meacham]

On Wed, Feb 01, 2006 at 08:52:16PM -0800, Isaac Jones wrote:
> 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.

it is because a user might want to use something other than runhaskell
Setup.hs (which appears to be what you mean by the 'setup' option) as
their custom build system.

build-style: setup
would be equivalent to
build-style: custom runhaskell Setup.hs

for backwards compatability cabal files without a build-style field
would be interpreted as build-style: setup

I never wanted to disallow Setup.hs, but it should not be the required
way to do things.

> > 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 :)

arn't a lot of them IO ExitCode anyway? that is because we probably
expect a lot of them to just be System.system "foo".

it seems like a very natural thing to add. like I said, the library
exists, but for something as simple as hooks that just call programs, it
should not be needed when cabal-install can take care of it.

> 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.

it is forcing them to. which is bad. no matter how beautiful haskell is.
Quadruply especially so since it does not gain you anything. since it is
not needed.

I don't see cabal files becoming anywhere near turing complete. then it
wouldn't be declarative (at least in the sense I mean). at most, string
interpolation will be the only operation on its fields.

I am actually trying to simplify cabal a lot with these changes. a
program is hugely simpler than a library. Just from a maintenence point
of view, must of the issues dealing with syncing cabal and ghc releases,
cabal library version changes, etc would just have never been issues.
what about multiple compilers and keeping your cabal installs in sync
among all of them? it is just a big mess. 

not to mention how much simpler cabal development will be once it is
decoupled from the compiler libraries and can evolve independently.

> 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.

no, in the current situation you have no _choice_ but to bail out into a
turing complete langauge. which will promptly be used to get back into a
standard library most of the time which has already been linked into the
executable that bailed you into the turing language to begin with. it
really seems silly. especially when there are so many pitfalls. I really
don't see how it can be considered a good idea to force a users hand
when you don't have to, and can simplify things in the process.

at least with a build-style: option then meta-tools can look and
imediatly know which packages it needs to handle specially. you don't
even have that option if everything is _required_ to use a program. A
program that can modify arbitrary things at that. want to build the
program as a user and then just do the install as root? well you are
going to be running arbitrary user code as root since you need to to do
a runhaskell Setup.hs install. rather than having to audit every program
you install, you just need to look at the ones with install-hooks. 

Easy things easy and hard things possible. making cabal a library
definitly makes easy things possible, but certainly not easy.

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈