new Library Infrastructure spec.

[Isaac Jones]

"S. Alexander Jacobson" <haskell at alexjacobson.com> writes:

> Isaac,
>
>> I don't think the "runhugs" bit is a requirement.  You can execute the
>> setup script however you like.
>
> 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.

On Unix, this might look something like a shell script, let's call it
haskell-install, which does the following:

wget http://packages.haskell.org/Foo
unzip Foo
cd Foo-version
./Setup.lhs configure
./Setup.lhs build
./Setup.lhs install

# where install --user if run by non-root.

or alternately:

wget http://packages.haskell.org/Foo
unzip Foo
cd Foo-version
ghc --make Setup.lhs -o setup
./setup configure
./setup build
./setup install

This works whether Setup.lhs wraps a makefile system or whether it
wraps Distribution.Simple.  That is the virtue of having a standard
interface, and what I've meant by "layered tools".

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.

> Where some.pkg is some combination of tarball and
> setup specification.  The install system of the
> compiler/interpreter would retrieve some.pkg from
> the specified location, and use the setup spec to
> compile it and put it in the appropriate locations
> such that Joe can use it from his Haskell program
> or perhaps invoke it as an executable in whatever
> manner is appropriate to his local OS (mouse-click
> or command-line).

Right.

> 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".

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.

Marcus has to wrap his makefile system with the Setup script.  He uses
Distribution.Simple to parse the command-line, but that's it.  He
doesn't know or care how Joe's operating system implements
haskell-install.

> Marcus creates packages that require some combination of GCC and
> Perl and perhaps some random Perl libs from CPAN to build.  There is
> really no way to make installation of systems he creates simple and
> generic.

Autoconf and friends implement this.  We provide an interface which
wraps both autoconf and Distribution.Simple.

This isn't a new idea, in fact.  apt (in Debian) does this, the ports
system in BSD does this.  Will it work perfectly to be able to install
the Perl dependencies for Joe?  No.  If he wants that kind of support,
he'll have to get it from his operating system.

In summary, depending on your point of view, there are many ways to
make installation of such systems simple and generic.

> My feeling is that we shouldn't even bother to try.  Marcus and Sam
> both know enough to communicate effectively to make it happen and
> neither of them is going to be happy trusting some generic install
> script to get it right on their totally customized systems!

What's this generic install script you speak of?  StaticSetup?  Of
course, I agree that StaticSetup doesn't get us what we want.  Neither
will Distribution.Simple, but Marcus isn't using Distribution.Simple.

Sam has been perfectly happy for years using "./configure;make;make
install".

> Angela OTOH knows little about platform dependencies and other stuff
> and simply wants to make a couple of Haskell libraries available
> with minimum hassle.  Angela would almost certainly prefer a system
> in which the compiler can guarantee her that her package will
> install correctly on all conforming Haskell compilers to a system
> where she has the full freedom to script arbitarily complex
> installation and make arbitrarily obscure mistakes on any system.

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.

OTOH, Marcus needs something more flexible.

I'm not sure if you really mean compiler here, but I really don't
think this should be closely tied to the compilers (as in the ghc
--install example above).  Let the compilers compile the code, we'll
layer tools on top of the compilers to do the packaging and
distribution stuff.

> PPS I realize that you really want to suport Marcus as well.
> Perhaps it might make sense to separate hc-pkg from the rest of the
> document?

I don't understand what hc-pkg has to do with Marcus in particular?

peace,

  isaac