new release of LIP prototype API

[Graham Klyne]

I'm reading (belatedly) through your proposal doc, and have some 
questions/comments:

...

Section 3:
[[
As mentioned above, the foremost user interface for this system will be a 
Haskell program to be executed by the default Haskell Implementation. This 
Haskell program, Setup.lhs, will perform the tasks of building the package 
(where necessary), installing the package, and making the package available 
to the system.
]]

I'm guessing this setup program to be part of each library "package" 
distribution?

...

Section 3.3 (comment):

Depending on which Haskell implementation has been installed, and how, 
running setup.lhs directly may not be an option under Windows, especially 
if it needs to access non-standard support libraries.  So there may be some 
operating-system dependent variations in the command line structure.  I 
don't think this is a serious problem, but I expect one might end up with a 
command line structure with two parts:

    [run setup program] [command line to setup program]

where the first part may vary between operating systems, or even 
installations.  The important part (the second part) should be commoin 
across systems.

...

Section 3.4:
[[
main = defaultMain toolInfo id id
-- Those last to parameters might be pre-install and post-install functions
]]
s/to/two/?

...

Section 4.2:
[[
... but Haskell should offer a more robust set of file operations in order 
to encourage the use of Haskell for common scripting tasks.
]]

I do agree.  This an area where I find, say, Python is very strong.

The other area that I think needs to be abstracted uniformly across systems 
is running and interacting with external programs;  e.g. as POpen does for 
Unix systems.

...

Section 4.3:
[[
To let the Haskell Implementations know how to use a package, whether its 
available by default (or whether it requires a -package flag), and where 
the root of its hierarchy is.
]]

This comment about the -package flag intrigues me.  Is it not the goal that 
this library infrastructure will eventually displace (what I understand to 
be) the GHC-specific packaging framework?  I guess it may still be needed 
as a transition measure.

...

Section 4.3:
[[
       All information will be made available through the 
Distribution.Package module. The information can be made available to 
non-haskell tools by way of a command-line tool, haskell-config (Section 
4.4) with easily parsable output (similar to package-config) though a 
different solution may be necessary for windows.
]]

I'm not sure I fully understand, so this may be irrelavant...

A colleague recently told me that the current Windows "badging" 
requirements are for applications to *not* keep configuration information 
in the registry, but to use an XML file in the same location as the 
executable program.  Hooray!  Maybe we'll start to see the end of the 
abominable registry monster?

Anyway, the idea of keeping and/or presenting configuration information as 
an easily parsed file format seems to me to be quite appropriate for Windows.

...

Section 4.3.1:
[[
The package data structure might look something like this (based on GHC's 
Package class)

data PkgIdentifier
     = PkgIdentifier {pkgName::String, pkgVersion::Version}
...
]]

Glancing at this, I wonder if this isn't getting us rather locked into a 
fixed structure of information?  If future requirements should emerge, is 
there any easy way to accommodate them without breaking existing config 
data?  If the datatype is purely internal and transitory, then I suppose 
there's no real problem as long as a strategy for extensibility is in place 
w.r.t. the stored config format.

...

Section 5:
[[
This may include writing functionality so the compiler can be asked 
questions about itself.
]]

This reminds me that I think it would be good if all Haskell 
implementations had a (simple) library module that would return key 
information about the compiler environment (operating system, hardware 
architecture, install directory, library base directory, file system 
characteristics, etc.)  I have been surprised to find none of this in the 
standard System module.

...

Section 7:

I think the first 4 bullets would represent a big win.  Beyond that, I 
think the 6th bullet (external tool/library support) would be the next most 
useful.

...

General.

On a quick read through, this looks very good to me.  I felt that I didn't 
fully understand all the intricacies of what is discussed, but that will no 
doubt become clearer when I start to use and/or create packages that use 
this framework.  I'll try and find time to look at the code again, and see 
if I can figure out some details from there.  (Is there a package example 
in there?)

Which raises an idea I don't remember seeing:  does a package configuration 
include information about installation test modules?  I'm thinking that it 
would be good practice for packages to include an HUnit-like test module 
that can be used to instill confidence that the installation is working as 
intended, and that there should be a common way to find it and run it.

How do you overcome issues of system dependencies in advance of having a 
common method across implementations to access key information?  Maybe a 
simple configuration file and an environment variable to point at it could 
be used in advance of widespread language implementation support?  That 
way, a simple script and/or editing process might be used to bootstrap the 
system.

#g
--

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'm going to be focusing more on the Build stuff (rather than the
>packaging stuff) for a little while, but with luck, this can be near
>to finalization soon.
>
>The web page is here:
>http://www.haskell.org/libraryInfrastructure/
>
>Feedback and volunteers for coding are always welcome :)
>
>peace,
>
>isaac
>
>ps. I'm using arch (tla) for version control, so if you've been
>wanting to check it out, now is a good time :)
>
>------------------------------------------------------------
>
>lookupPackage :: PackageDB -> PkgIdentifier -> Maybe PackageConfig
>addPackage :: PackageDB -> PackageConfig -> PackageDB
>
>delPackage :: PackageDB -> PkgIdentifier -> (PackageDB, Bool)
>allPackages :: PackageDB -> [PackageConfig]
>createPackageDB :: FilePath -> (PackageDB -> IO PackageDB) -> IO ()
>
>withPackageDB :: FilePath
>               -> (PackageDB -> IO (PackageDB, a))
>               -> IO a
>
>userPkgConfigLocation   :: String -> FilePath
>userPkgConfigLocation home = home ++ "/.haskell/packages.conf"
>
>systemPkgConfigLocation :: FilePath
>systemPkgConfigLocation = "/etc/haskell/packages.conf"
>
>PackageConfig(..),
>PkgIdentifier(..),
>License(..),
>Dependency(..),
>PackageDB
>_______________________________________________
>Libraries mailing list
>Libraries at haskell.org
>http://www.haskell.org/mailman/listinfo/libraries

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