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@haskell.org http://www.haskell.org/mailman/listinfo/libraries
------------ Graham Klyne For email: http://www.ninebynine.org/#Contact