new release of LIP prototype API

[Graham Klyne]

At 22:58 17/02/04 -0500, Isaac Jones wrote:
>Greetings,
>
>I just uploaded a new release of the Library Infrastructure prototype
>API for Distribution.Package and the command-line utility
>"haskell-config".  The API for package configuration is included
>below, FYI.

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!)

Looking at the LIP from the point of view of installing some LIP package in 
a target environment, it seems to me the following details need to be 
addressed, somehow:

(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?

(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?

(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?

(4) There are many more possible questions about things like dependencies 
between installed packages, system requirements, compiler requirements, and 
other secondary configuration information.  I think these issues would be 
easy to track down once the description basic relationship between 
compiler/library/programmer is exposed.

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?

I'm fishing here for clues to help me locate the free end of the string, so 
I can start to unravel it.

...

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.  Do you envisage a fixed location for each 
kind of system?  For Windows, it's common to keep additional data  and 
/etc/ stuff in the same directory as the executable program;  IIRC the 
Windows API provides means to locate that directory.  Also, under Windows, 
its possible to define environment variables that are defined for all 
users;  I'm not sure if Unix/Linux provides an equivalent.

...

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.

...

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?

...

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?

My thought is either: (1) to apply a ladder something like this:
(a) look for a specific environment variable, say 'HaskellLibConfig', which 
can be configured to point to the config file
(b) look for environment variable HOME
(c) look for environment variables HOMEDRIVE and HOMEPATH (Windows 
equivalent of HOME) and use a fixed default filename ... this will work as 
a per-user default if the explicit environment variable is not set.
(d) [try some system-dependent convention for MACs and other computer systems]

or (2), when installing the LIP software on a machine, select a 
system-dependent module that performs an appropriate series of tests, so 
that we might have:
Unix:    (a) Env:HaskellLibConfig, (b) Env:HOME, (c) /etc/HaskellLib.conf
Windows: (a) Env:HaskellLibConfig, (b) Env:HOMEDRIVE+HOMEPATH,
          (c) <LibSoftware>\HaskellLib.conf (where <libsoftware> is the
              executable program directory reported by Windows
Other:   (etc...)

Generally, my feeling is that there should be a fairly easy means to 
specify exactly where the config file is kept, with a fallback to a 
reasonable default if that means is not employed.

...

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

(Time to go off and learn about hmake, I think.)

#g


------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact