On Mon, 7 Jun 2004, Isaac Jones wrote:
Any reason we can't simplify Joe's interface to:
ghc --install http://url/of/some.pkg
--or--
hugs --install /path/to/some.pkg
This is quite explicitly something we're trying to support. The original document, and my talk at the Haskell Implementor's Meeting, had some exampled of "layered tools" for the system, including exactly this use. I should probably re-add that to this version of the proposal.
This interface should be _fundamental_. JoeBob*, and Sam are indifferent to how it is implemented. It should just work if the compiler/interpreter is installed correctly. [...sample shell script implementations elided because implementation is irrelevant to this discussion... question: Why are the sample implementations not themselves in Haskell!?...]
One version of haskell-install is written for Windows, one for unix-a-likes. Or maybe Debian will implement one to set the --prefix flag to /usr/local/ghc/libs or something.
Whatever. Just so long as all JoeBob has to do is "gnhugc --install foo.pkg"
The open question is what this setup specification should look like. There is an obvious tradeoff between the interests of Joe and Angela on the one hand and Marcus on the other.
I think our scheme satisfies Joe, Angela, and Marcus. All Joe knows is that he says "haskell-install".
At least in the proposal so far, someone has to deal with "runhugs" or whatever. --install should be standard for every compiler/interpreter just like --package.
All Angela knows is that she fills out the (declarative) fields required by Distribution.Simple. She doesn't know or care how Joe's operating system implements wget.
Or even IF Joe's os implements wget. Why not implement in Haskell to avoid this issue?
Angela does have this. She can use Distribution.Simple. She's not doing arbitrary or obscure IO. The example we give is very declarative for her.
Sorry, where is the example. 1.2 does not include telling the system that Angela.Internals is private to Data.Set and Data.Bag. 3.4 is empty as is 5.3. My concern here is in particular that the (declarative) fields are not yet fleshed out even though they are the most important part of this sort of proposal!
Autoconf and friends implement this. We provide an interface which wraps both autoconf and Distribution.Simple. Sam has been perfectly happy for years using "./configure;make;make install".
So, why are you making Sam do something different for Haskell?
OTOH, Marcus needs something more flexible.
Is there some substantive problem with autoconf/make with respect to Haskell such that it needs to be wrapped with Setup.lhs? If I have a package that is part C, part Python, and part Haskell, why is it reasonable to assume the outer-layer is necessarily Haskell as opposed to e.g. Python's dist-utils? Or does Marcus need to strategize whether the outer layer is dist-utils or HPS and then have one call the other? Note: I read section 2.5, but that seems like an argument for writing an package system in Haskell regardless of the language of the code to be installed. All of which takes us back to my prior point about using Haskell to address generic problems in autoconf/make rather than solving the Haskell package problem in particular -Alex- * I don't believe Joe and Bob are different people so I am consolidating them as JoeBob. In particular I don't believe that Joe user should have to get someone else's help to do a simple install. _________________________________________________________________ S. Alexander Jacobson mailto:me@alexjacobson.com tel:917-770-6565 http://alexjacobson.com