new Library Infrastructure spec.

[S. Alexander Jacobson]

Perhaps it makes sense to define the mission more
precisely.  The document begins:

  The Haskell Library Infrastructure Project is an
  effort to provide a framework for developers to
  more effectively contribute their software to the
  Haskell community.

Does "software" include an IDE written in C,
Python, or Java?  Does it include GHC itself? Are
we really trying to design a Haskell wrapper
around autoconf, make, or Installshield?  Why
reinvent the wheel?

Given that this document is part of "Library
Infrastructure", perhaps it makes sense to
restrict the mission to:

  The Haskell Library Infrastructure Project is an
  effort to provide a framework that makes it easy
  for Haskell developers to package *haskell
  libraries* for easy installation into any
  Haskell development environment.

Following this more restricted mission, the HPS
would be something that autoconf calls to interact
with the local Haskell environment rather than
vice-versa.

Perhaps it makes sense to work through some actual
real life examples.  If I have a package that
combines C, Perl, and Haskell?  How should I
distribute install it?  HPS or Autoconf?

-Alex-

_________________________________________________________________
S. Alexander Jacobson                  mailto:me at alexjacobson.com
tel:917-770-6565                       http://alexjacobson.com






On Thu, 3 Jun 2004, Isaac Jones wrote:

> "S. Alexander Jacobson" <haskell at alexjacobson.com> writes:
>
> > On Wed, 2 Jun 2004, Isaac Jones wrote:
> >> Here are some more issues you're scheme will have to deal with:
> >>
> >> 1) Marcus Makefile.  He's important to us; he's a hard-core haskell
> >>    developer and we want to support him.  How does he go about calling
> >>    through to the "make install" command?
> >
> > I thought this proposal was an alternative to
> > "make install."  Are people doing things with
> > makefiles that can't be done using StaticSetup?
>
> It's important to remember that the Setup script is an _interface_
> that hides underlying complexity.  Under the hood might be
> Distribution.Simple (section 5.3), or it might be a bunch of
> makefiles, or it might be hmake, or it might be a haskell program that
> you write yourself.
>
> We're trying to give the end users (and tools that may be layered on
> top of the packaging system) a consistent interface to packages whose
> needs and underlying implementations are very different.  (Think of
> the different kinds of needs between HUnit and wxHaskell).
>
> Now Distribution.Simple is a particular implementation of this
> interface which is meant for very simple libraries and tools.
>
> What you propose to provide is a secure infrastructure for building
> and installing very simple libraries and tools, but not providing a
> common interface across diverse libraries and tools.  I feel that this
> is a completely different goal.  (I also think that if this is what's
> desired, the user is better off using a packaging system that has more
> guarantees, and not installing code from untrusted sources at all (see
> my work in "apt-secure" btw) but that's neither here nor there.)
>
> >> 2) If you allow executables to be installed, you'll have to watch out
> >>    for attacks which replace "ls" or something.  I guess you could
> >>    have a warning for any package which tries to overwrite an existing
> >>    file, though this may happen a lot for upgrading a current library.
> >
> > But typically it would happen all within the same
> > directory so there it should be possible to offer
> > the user the option to accept all updates to a
> > particular directory.
> >
> > Simply telling the user in which directories
> > updates may be happening is a big plus.
>
> That's a good point.
>
> >> 3) There is some grey area between the Angela and Marcus use cases
> >>    where she can perform extra preprocessing steps and configuration
> >>    steps within the context of Setup.lhs (since she has all of Haskell
> >>    at her disposal.)  In your scheme, there is no space between Angela
> >>    and Marcus. You're either in or out when it comes to utilizing
> >>    Distribution.Simple.
> >
> > I'm not sure I follow here.  Nothing stops you
> > from chaining/recursive StaticSetup...
>
> I don't know what you mean by recursive StaticSetup, so I'll try
> again.
>
> Distribution.Simple provides some mechanisms for making Angela's life
> easier, especially with very simple libraries.  Now say Angela has a
> library that uses Distribution.Simple, but she's altered it to utilize
> the Happy preprocessor, and (let's say) Distribution.Simple doesn't
> know anything about Happy.  Now Angela can add a "system" call to her
> Setup file to preprocess what she needs to, and continue using the
> rest of the Distribution.Simple mechanism she was using before.
>
> In the StaticSetup scheme, Angela is out of luck.  She can't change
> the behavior of StaticSetup to do the right thing, so she has to get
> rid of her build system altogether and start from scratch with
> makefiles or something.  This is what we want to avoid.
>
>
> peace,
>
>   isaac
>