On Mon, 21 Mar 2005 22:06:25 -0500 (Eastern Standard Time), S. Alexander Jacobson <alex@alexjacobson.com> wrote:
Lemmih,
The current Haskell/Cabal module and packaging system is substantially annoying for the typical non-sysadmin end-user. In particular, if they move their code to another machine they have to do a bunch of different administrivia including:
1. knowing the source package for each module used in their code even if they didn't insall the packages in the first place i.e. import Foo.Bar just worked on my development machine.
I'm not sure I completely understand what you're saying but knowing the exact URL for every single module import seems more of a hassle than installing a few packages. You could perhaps even make a shell script containing 'cabal-get install package1 package2 ...'.
2. knowing the current location of those packages even if they didn't obtain them for installation on the original machine where they used them and aren't on the mailing list for them.
I assume you meant something like "The developer don't know where to find the packages". The location of the packages is irrelevant to the developer since it's handled by Cabal/Hackage.
3. going through the hassle of doing a "cabal-get install" for each of them once they have figured it all out.
See the above mentioned shell script or cabalize your software.
I'd rather have a system that takes care of 1-3 for me and just reports errors if particular modules are irretrievable.
That being said, Cabal definitely solves a lot of problems that my original proposal left unaddressed (e.g. producing executables needed to build modules, handling C code, versioning?). Perhaps the correct answer is to import Cabal packages rather than haskell source e.g.
import http://package.org/package-1.0.cabal#Foo.Bar as Baz import http://package.org/package-2.0.cabal#Foo.Bar as Baz2 --note use of HTTP fragment identifier for module name
Requiring Haskell implementations to honor this would be very bad, IMHO. A preprocessor which looks for package pragmas ({- USE somepackage -} perhaps) and install those packages via Cabal would be way easier to hack. But then again, a small script to fetch the packages or a .cabal file would be even simpler.
And a big bonus here is we get a simple solution to the problem of Haskell's global module namespace.
There was a problem with module name spaces? Wouldn't there only be a problem if two packages used the same module name for different functionality?
Now module namespace is local to individual packages.
If cabal also has a "cabal-put package MyPackage http://myhost.com/dir" then we have a really simple and beautiful system for sharing libraries over the Internet as well!
This is essentially what Hackage does.
If the change of import syntax is blessed by the powers that be, would it be hard to adapt Cabal to work like this?
Extending the Haskell syntax to include something which could easily be handled by a preprocessor would be inadvisable.
-Alex-
______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
-- Friendly, Lemmih