[Haskell-cafe] expanded standard lib

[Alex Young]

Magnus Therning wrote:
> On Wed, Nov 21, 2007 at 20:40:01 +0000, Alex Young wrote:
>> 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):
>>
>>   http://www.nabble.com/-ANN--RubyGems-0.9.5-tf4840470.html
>>
>> 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.
> 
> All I was trying to say is that if discussions like the one you link to
> can be avoided altogether then that would be good.
Indeed it would.

> I have never been heavy into Ruby programming, but I thought that the
> location for gems was the least of the problems they list.  The major
> one, IFAIU is:
> 
>  “Rubygems is source-intrusive. The require instruction is replaced by a
>  require_gem instruction to allow for versioned dependencies. Debian and
>  most other systems think that dealing with versioned dependencies
>  outside of the source is a better idea.”
This particular objection has the distinction of being both wrong and 
outdated.  The require_gem method was deprecated some time ago, and 
versioned dependency control has always been available to package 
management outside the source, in the gemspec, as well as having a 
runtime check available to the software author.

> And it's not only a problem for Ruby in Debian:
> http://people.debian.org/~terpstra/message/20070904.152810.4f84c924.en.html
> 
>  “There are currently no plans to improve RubyGems to ease the work of
>  Debian and RPM packagers.”
It's the position of the RubyGems team that all the functionality that 
should be needed has been implemented, but they've made it quite plain 
that they're willing to accept reasonable patches (as they have done 
from Apple).

> I think that making it easy to package Haskell libraries, and programs,
> for any OS/distribution (Debian, Gentoo, PC-BSD, windows, etc) is
> /extremely/ important.  I for one would like to see programs written in
> Haskell make it into as many places as possible.  I'd hate to see a
> Haskell-specific packaging system prevent that in a similar way that
> RubyGems does.
I am yet to be convinced that RubyGems prevents anything, but then I'm 
not a maintainer on either end.  I certainly believe that it's possible 
to avoid inconvenience.

> From the Debian Ruby team again:
> 
>  “[Users can] continue to install their apps the way they are used to
>  (using apt-get), since most of them do not care about the language
>  their apps are written in or about other ways this application/library
>  is made available.”
That section specifically refers to libraries and applications that are 
not distributed as RubyGems, and that therefore can't take advantage of 
the cross-platform distribution and dependency management system. 
That's a (relatively) shrinking number.

Again, I'm not convinced that the two can't be made to co-exist; that 
is, that an apt-get installed library should be gem update'able, and 
vice versa, and have everything still work.  The upshot of the current 
situation of Ruby on Debian is that the standard advice seems to be to 
build everything from source; luckily, that works extremely well.

We're in danger of drifting OT here, but I think the lessons are important.

-- 
Alex