RE: Haskell library infrastructure coordinator
Peter | I wanted to write up a proposal regarding the organization of a | >central< library infrastructure for weeks Terrific! | ... So I guess now is the time to do or die. No, no, absolutely not! The idea is *not* that the coordinator goes into a corner and produces something that s/he imposes on the rest of us. The idea is that s/he asks for ideas, makes proposals, and moderates the process of melding those ideas into a design we can all support. Step 1 : identify coordinator Step 2 : propose designs, discuss, evolve consensus Step 3 : implement My message only concerned step 1. Yours is about step 2. Which is excellent, but it *isn't* do-or-die time for step 2. Simon
Simon Peyton-Jones writes:
Step 1 : identify coordinator Step 2 : propose designs, discuss, evolve consensus Step 3 : implement
My message only concerned step 1. Yours is about step 2. Which is excellent, but it *isn't* do-or-die time for step 2.
Sorry, my wording was probably misleading. I didn't mean any disrespect or opposition to Isaac Jones. The comment was purely meant along the lines of: "Peter, you have been thinking about this for weeks, so get it done already!" Ketil Z. Malde writes:
It seems to me that binary packages should be mostly optional, and can be deferred to the compiler developers to snarf from the "hslibs" (stable) hierarchy and include at their leisure?
I agree. Binary packages are can of worms. I remember when boost.org tried to come up with a way to build and install them, and the effort more or less failed, because designing an OS-independent mechanism is incredibly hard. They ended up writing a complete build system of their own (bjam) and today (2 years later) it still cannot do the equivalent of "make install". That's of course no reason it couldn't be done anyway, but it's definitely not a trivial task. And it doesn't end with building and installing: You want to have automated regression testing, generation of documentation from varying input formats, and so on, and so forth. So if we can get along without building the library ourselves at all, it will make our life much easier -- and I'm sure most developers won't care anyway. I, for one, do prefer source codes, like Ketil does. Peter
Peter Simons
Sorry, my wording was probably misleading. I didn't mean any disrespect or opposition to Isaac Jones. (snip)
None taken!
Ketil Z. Malde writes:
It seems to me that binary packages should be mostly optional, and can be deferred to the compiler developers to snarf from the "hslibs" (stable) hierarchy and include at their leisure?
Binary packages can also be provided by distribution maintainers (like a Debian maintainer). I read over Peter's proposal, and I consider it more of a distribution proposal than a library infrastructure proposal. So far I have been thinking of distribution infrastructures as the last step in the process, there are some immediate issues that I see however, and none of these are showstoppers. - On the good side, there are probably a lot of orphaned libraries that need a home. haskell-libs would be a good place for storing them and helping them to percolate into a repository of more useful libraries. - Despite being an open CVS tree, the approach is rather "cathedral". I have been thinking that we want a standard way for individuals to distribute libraries and tools, and then to create a central repository of those once the library authors conform to a particular interface. - Some authors won't want to store a copy of their code on another CVS repository if their projects already have a home. This could cause redundancy and / or forking. I'd be interested to see how your proposal fits with mine in your eyes. As I mentioned, this discussion illustrates the need for us to come up with a set of requirements. I think that you and I see similar solutions, but they are somewhat upside-down from one another. Also, you mentioned hbuild, can you discuss how this improves upon hmake? peace, isaac
Isaac Jones writes:
[distribution vs. infrastructure]
You are right: Apparently we were approaching the issue from different sides. :-) My biggest problem so far is that there are numerous one-module libraries out there, which are very useful (DeepSeq, POpen, Shell-Haskell, etc.) and which require no "building" or "installation" at all. But it is very annoying to collect them and to keep the local copies up-to-date. Also, distributing them as part of my packages may cause license problems, users won't benefit from possibly available newer versions they have installed, and so on. But then I cannot distribute my package and expect the users do download a dozen small files from all over the Internet in order to compile it either. Solving _this_ problem is what motivated my proposal. Obviously, more complex libraries will occasionally require special pre-processors or multi-staged compilation, and then the build system issue will come back to haunt us. But this is rare; even fairly sophisticated code like HaXml or Functional MetaPost can be compiled with "ghc --make" or "hmake" without any problems.
- Despite being an open CVS tree, the approach is rather "cathedral".
I think it combines the best of both worlds: The "unstable" area serves as the bazaar, where people can do whatever they want. Whereas the "stable" area should provide production quality libraries. At the very minimum, the APIs of code in there should not change from one day to another.
- Some authors won't want to store a copy of their code on another CVS repository if their projects already have a home. This could cause redundancy and / or forking.
True. This is why I came up with cvssynch, so that the project could import code from other repositories in a semi-automated fashion -- without forking. But ultimately, it's up to the library author.
I'd be interested to see how your proposal fits with mine in your eyes.
From what I understand, your idea aims for something even bigger than mine: You'd like to have a tool infrastructure, which can retrieve, build and install pretty much any library for you, like the "ports" system of BSD Unix, right? I like the idea very much, and the two approaches are not mutually exclusive at all. Such a system could, for instance, easily fetch and build "hslibs" -- just like any other library it supports.
So maybe we're talking about two separate but related projects, actually?
Also, you mentioned hbuild, can you discuss how this improves upon hmake?
HBuild is going to be a full generic "make". The only difference to ordinary make tools is you don't write a Makefile, you write a Haskell program using a monadic combinator library, which you compile to get a project-specific build tool. You can think of "runhugs" to represent "make" and the Haskell source code to represent the "Makefile", if you want. :-) This is really work in progress, though. I'm having a lot of trouble coming up with a satisfactory design of the library, precisely because building software is so messy. (I already mentioned variant builds in an earlier post, for example.) Anyhow, HBuild is not really essential to the idea of the hslibs repository. (Neither is cvssynch.) It's just something I have been experimenting with ... Peter
participants (3)
-
Isaac Jones -
Peter Simons -
Simon Peyton-Jones