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) we should add a field to the cabal file: build-style: simple build-style: make build-style: custom runhaskell Setup.lhs build-style: custom runhaskell MyBuild.hs -c % where custom will just run its value passing through arguments to it. '%' should be filled in with the name of the current cabal file so it need not be seperatly specified to your custom handler. 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.
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 definitly think cabal-install should be an independent project on its own. it should also come with the 'runhaskell' script that has the logic currently in cabal-install to choose an appropriate runghc vs runhugs vs runjhc as appropriate since that makes sense also as a compiler independent project and distributing it with cabal-install seems like a natural choice. (especially since the logic is already implemented in there)
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.
these are laudable goals, but seem somewhat independent. We need a working cabal-install now. we can easily start building better tools on top of it then since for 90% of projects it will already be feature complete. <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> John -- John Meacham - ⑆repetae.net⑆john⑈