[Haskell-cafe] expanded standard lib

Alex Young alex at blackkettle.org
Wed Nov 21 16:10:20 EST 2007

Magnus Therning wrote:
> On Tue, Nov 20, 2007 at 12:33:21 +0000, Vladimir Zlatanov wrote:
>> Yes, those are good points. Maybe adding functionality similar to plt's
>> planet http://planet.plt-scheme.org and
>> http://download.plt-scheme.org/doc/371/html/mzscheme/mzscheme-Z-H-5.html#node_sec_5.4
>> In plt scheme including a module, not present in the local repository ,
>> but included via planet, resolves the module, including version,
>> etc..., downloads it from planet, and uses it appropriately. It makes
>> following various dependencies extremely easy. Updating with a new
>> version is updating the appropriate local module definitions.
>> I have no clue how it would be best to implement this for haskell, but
>> it is a very user friendly no hassle way to work, so I reckon worth
>> investigating.
> Many other programming languages have packaging strategies that sound
> very similar.  Several of them have managed to have a negative impact on
> platforms that already have good packaging technologies (i.e. almost
> every platform apart from Windows ;-).  I'd hate to see Haskell go in a
> direction where packaging for e.g. Debian is made more difficult than it
> is at the moment.
> See [1] for the Debian Ruby packagers' opinion of RubyGems.  IIRC
> similar concerns have been raised for Python's eggs.
> /M
> [1]: http://pkg-ruby-extras.alioth.debian.org/rubygems.html
Much of that's either outdated or just plain wrong, as I understand it.
In the interest of balance, note the following thread on ruby-talk,
which devolved fairly rapidly into a bunfight over Debian's policies
(and a comparison with Apple's approach to the same problem):


There are arguments on both sides, but the utility of having RubyGems
available far outweighs the minor inconvenience of having to install
RubyGems outside apt as far as I'm concerned.


More information about the Haskell-Cafe mailing list