new Library Infrastructure spec.
ariep at xs4all.nl
Fri Jun 4 18:10:01 EDT 2004
At 18:12 2004-06-03 -0400, Isaac Jones <ijones at syntaxpolice.org> wrote:
>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.)
I do not understand why a strictly defined data structure would not be a
common interface, and why a (for ignorant windows users like me, at least)
obscure and opaque makefile would.
Do you mean by 'interface' the way in which a user invokes the
installation? I would like to be able to choose whether I type "make
install" myself, let a linux package manager handle that for me, or perhaps
use some customised homemade install manager to give me exactly the
information and options I want. Alex' idea of an installation data
structure suits that wish perfectly. As mentioned before, it would be
particularly nice to know what files/directories are to be modified or added.
>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.
If the preprocessor is to be executed by the user, then this is just a
dependency and can be listed as such in the install structure.
If the preprocessor is to be executed by Angela, then she does so happily
(sorry ;-)) and the user need not know that a preprocessor was used.
Am I missing the point?
Let me suggest a different approach.
We could define a Setup/Installation monad, together with some some
primitives (display a message, ask for user input, move files, check
dependencies, request installation of other packages, etc.). One special
primitive might be 'IO', containing an arbitrary IO operation, to
accommodate installation actions that cannot be defined in terms of the
A package description/installation might consist of a haskell data
structure, holding some basic properties of the package and a Setup ()
This package structure may be distributed:
1. as haskell source code alone, to allow users to install the package with
their own customised installer or a default ghc installer;
2. in source form with an installer that the user may or may not use;
3. compiled by the author with her installer to produce a binary executable
Notice that an 'installer' in this context is a haskell program, typically
run with hugs or ghci (unless dynamic linking will be widely supported),
that merely has a Setup () as a parameter and interprets this structure on
the fly, in a way that the author of the installer thinks best: install the
package in the right directory, do or do not download necessary libraries
automatically, do or do not ask the user to authorise the IO parts,
register the program with the compiler of choice, etc.. The installer might
get settings from a conf file or bother the user with every detail - that
is up to the author of the installer.
I feel somewhat awkward to suggest this wild idea, because the proposal
seems well-thought out and quite mature.
So please convince me that this approach is useless :-).
More information about the Libraries