new release of LIP prototype API

[Isaac Jones]

Graham Klyne <GK at ninebynine.org> writes:

(snip)
> I've downloaded the latest, but I'm having a hard time getting my head
> around the overall structure.  It feels to me a bit like a tangled
> ball of string, whose free end I cannot find.  (This a comment on my
> understanding, not your code/design!)

:)

> (1) Library files are copied to some place on the target filesystem.
> Is it intended that they can be installed anywhere, or does the LIP
> software choose a location?  How is that location determined?

For now, this isn't addressed.  This is going to be in the middle
layer, the installation (Distribution.Install) layer, which is not yet
implemented or specified.

The only thing implemented right now is the packaging component, which
is an API for helping the Implementations to locate and use packages,
as well as a command-line tool for registering packages,
Distribution.Package.

> (2) It may be necessary that the library files need to be compiled on
> the target system.  I think LIP must know about the compilation and
> related tools available for this purposes.  How does LIP learn about
> these, and where is the information kept?

This information must be made available to the Distribution.Build
package.  I had originally intended it to be made available through
the Distribution.Package interface, where the compilers, etc are just
more packages.

I'm not so convinced anymore that this is the way to go, but the idea
is similar.  The compilers and preprocessors, etc, might register
themselves in a central location.  I hope that Distribution.Build
(which I'm sorta working on now, and which may end up being based on
hmake) will provide an API which glosses over some of the differences
between the compilers, at least for simple tools.

Right now, what hmake does is close to what we need.  Each installed
compiler is registered with hmake somehow, and it keeps track of what
features they have.

> (3) When a package is installed, its presence must be made known in
> some way, so that other programs that use the facility can find the
> appropriate files.  Where is such information kept, and how is it used
> when building a program that uses a library installed using LIP?

This is the part that is solved by Distribution.Package.  The
information is made available through that API.

> Generally, then, LIP must know things about the installed Haskell
> compilers, libraries, host system type, other tools, etc.  Where is
> this information kept, or how does LIP decide where it is kept?

It should all be available, I hope, through Haskell APIs like
Distribution.Package.  How will LIP _decide_ where to keep it should
be answered below.

> Maybe a clue I'm looking for is this:
> [[
> systemPkgConfigLocation :: FilePath
> systemPkgConfigLocation = "/etc/haskell/packages.conf"
> ]]
>
> But I don't see how the base config location can be hardwired into the
> code and be portable across systems.  

It is not intended to be.  Right above that you should have seen this
comment:

-- |Hopefully this can be grabbed from a more intelligent Directory
-- module.

This refers to a discussion on this list some months back:
http://haskell.org/pipermail/libraries/2003-October/001462.html

Well, lots of things are talked about in that thread, but the basic
idea is that I think we'd win a lot by coming up with some way to
populate something like those configuration file locations, but that
this is a specific case of a more general problem of getting system
configuration information like path separators, os versions, etc.

Several solutions were discussed, but no one has raised their hand to
implement one of them :) I'm hoping that this will magically happen
while I'm working on the other stuff.

> Also, looking at:
> [[
> userPkgConfigLocation   :: String -> FilePath
> userPkgConfigLocation home = home ++ "/.haskell/packages.conf"
> ]]
> I note that the Unix convention of using a name starting with '.' for
> "hidden" config files doesn't really work for Windows.

Yeah.  With a better system, I would expect to build that path like
this:

userPkgConfigLocation = Directory.userConfigDirectory ++ Platform.pathSeparator ++ packages.conf

Well, that's not perfect, but you get the idea.

The over-arching point is that if the standard APIs provided more
_infrastructure_ type stuff, like Distribution.Package and
Platform.pathSeparator, then most libraries could be taken out of the
ghc/nhc/hugs distributions and be more effectively distributed on
their own, or in nice collections.

> Looking at the API outline, and all those functions that operate on a
> PackageDB value, a question that occurs to me is:  where does the
> packageDB come from?  My best guess is that it's all bound up with:
> [[
> withPackageDB :: FilePath
>                -> (PackageDB -> IO (PackageDB, a))
>                -> IO a
> ]]
> which creates a PackageDB value, threads it through the I/O monad
> created by the second argument, puts the updated DB back to bed and
> returns some value derived from the process.  Am I close here?

Yep.  withPackageDB is the only way to get to the database contents.
Look at haskell-config/Main.hs for how it's used.

> I just spotted this as a possible way that LIP locates its config file ...
>
> In the file Main.hs, I see:
> [[
>           home <- getEnv "HOME"
>           let getPathH = getPath home
> ]]
> which value is used later in contexts that seem to name the config file.
>
> This does seem to be rather Unix-centric (isn't HOME a Unix/Linux
> environment variable for the user's login directory?).  And in any
> case, is this really something that ought to be configured on a
> per-user basis?

Yep.  It's unixy.  See above.  If you have any #defines I can add to
the code for windows, please pass them along.

The somewhat good news is that the config file locations are only used
for the --user and --system flags in haskell-config.  You can also use
the --config flag to pass the location of the package configuration.

(snip some good ideas)

> I hope my fiddling with this is more help than hindrance ... I think
> the project is an important undertaking for the Haskell world.

Always, and thanks :)

Let me know if I answered your questions well enough.  They are all
on-point and relevant.


peace,

isaac