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#nod...
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 as far as I'm concerned. -- Alex