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⑈