"S. Alexander Jacobson"
Also, I disagree with "They [Roland et al] do this as a service for Angela Author and the community."
1. Peter does this as a service for users of the platforms his packages target not for Angela or Marcus (it could be a disservice to A&M if they didn't want their packages distributed!)
OK. I'm sure there are many reasons Rowland et al package things.
2. Contrary to the proposal, those users should NOT need Peter's services to install Angela's pure haskell packages (the 99% case).
That's not contrary to the proposal. Such users don't *need* Peter's packages, but if they exist, the users will probably use them. (I know I would, and as a consumer of those packages, I don't care whether they're authored by Angela or Marcus.) (snip)
In any case, it seems much more important to flesh out the end-users experience and in particular the Windows end-user experience as it is probably the most common (and perhaps majority) case.
I'll add more personas and use cases to the proposal, and I will clarifiy those that are there. I will also clarify that these personas are not necessarily disjoint, since they're really more like use cases.
The reason that case is not included in this proposal is that it's outside the system as it stands now.
Yup. That is our disagreement. You are laundering in that user by wanting to wrap .rpm w/ setup.lhs.
We do not propose to wrap .rpm with Setup.lhs. Confused statements like this make me fear that you still do not understand my viewpoint.
My claim is that there are only two scenarios:
(1) Marcus -> Peter -> Wally/PNW (2) Angela -> Wally/PNW
Of course there are many more scenarios. What do you mean that there are only two? In fact, many Haskell programmers are probably nothing like PNW in that they know other programming languages and can compile tools written in other programming languages.
In scenario 1, I don't see what value the proposal adds over that provided by make/autoconf for Marcus -> Peter and InstallShielf for Peter->Wally/PNW.
I have explained this: 1) A consistent interface to users 2) A consistent interface to layered tools (of which I have given several examples) (snip)
All you're saying here is that your scheme doesn't support Marcus. I'm still waiting to hear why he's not important.
No. I'm saying that YOUR scheme doesn't really support Marcus. Or, more particularly, I'm saying that I don't see the value your scheme provides over autoconf/make -- especially given the assumption that Peter knows little or nothing about Haskell.
We provide Peter with value because all Haskell tools conform to a common interface, no matter whether Angela or Marcus wrote them. Packaging them therefore becomes easier. For instance, please take a look at the Common Debian Build System (cdbs), for which we can make a Haskell target to make Donald's job easier. I've mentioned this before. This is an example of layered tools. Note that cdbs isn't dpkg (the tool that installs debian packages).
This character (please, not Wally) can't install Marcus's package whatsoever. He's in no better or worse shape than before. For packages that "PNW" can install, our system still supports him.
But you can help Peter by giving him a simple interface that RPM or Installshield or whatever can use to install the Haskell specific components!
Yes. That is what we're doing. This interface works for packages by both Angela and Marcus.
If Peter knows little about Haskell, it makes little sense to force him to write a Setup.lhs that calls InstallShield.
You are still confused. Peter doesn't write Setup.lhs, and Setup.lhs doesn't call InstallShield. I still hold out hope that once you understand our proposal you will like it more than you seem to. (snip)
The proposal already makes demands on compiler authors and the proposal is for a mechanism to support mucking about in the files on which the compiler relies.
That the compiler authors have to implement hc-pkg is not a large demand, as it's very useful for lots of stuff, and I believe there are simple implementations for it already. It is not vertical integration.
How does the setup.lhs author know in which directory to put library files? (snip)
It depends on which author. Angela just calls defaultMain, which implements configure which figures that stuff out. Marcus presumably uses autoconf to figure it out. Bob (or the author of haskell-install) can over-ride the choice with flags to configure. Also, it doesn't particularly matter where they go, because register tells the compiler where they are. BTW, how does your system figure out where to put the libraries?
The document describes this workflow:
./Setup.lhs configure --ghc ./Setup.lhs build ./Setup.lhs install
So this means that Angela needs to know how to install her package for GHC? and NHC?
Nope. Another clear point of confusion, and a huge one. The Distribution.Simple module does that for her. (snip)
What happens if I've customized my local config substantially?
Then you should know how to pass options to ./Setup.lhs configure, or you should somehow make your customization information available to haskell-install. I can see that the proposal is lacking in a number of areas, and I hope to fix that. You have highlighted a few concrete areas where we need to be more clear. That said, but the proposal is meant to introduce the system at a high level, and as I say on the web page, I expected people to be familiar with previous discussions on this list. I hope you will take the time to fully understand our system before you continue to condemn it. Please do go to the trouble of reading the old proposal and my presentation, and even some of the list archives. These are all linked to on the "library infrastructure" front page. peace, isaac