Let's be really specific about what we want to have in this regard:

1. repo hosting
2. repo searching
3. A shared/federated name space mapping module names to the URLs of repos that implement those modules
4. A dev system that uses the name space to download and import chase the modules necessary for your program to run
5. A build system that takes a program name and builds/installs it on your system

For #1, web hosting with ssh access is really cheap and easy.  I've seen hosting as low as $1/month.  If people here are really unsatisfied with all the hosting out there.  I am happy to provide simple darcs hosting on one of my servers for a pittance.

For #2, google works pretty well.  Is there functionality we need that it misses?

For #3, I made a start with <http://searchpath.org/default.map>.  If people want me to add other packages to that namespace let me know.  Conceptually, the namespace is federated because you can combine that file with other files to build a composite namespace.

For #4, I made a start with SearchPath (available at http://searchpath.org).  Searchpath looks at the source of the haskell module passed on on the command line and then does recursive import chasing accross the internet using the set of module maps passed on the command line.  Currently, is does not handle well modules that use cpp to import code and it doesn't handle at all modules that have dependencies on C libraries that are not already local and on the path.

For #5, the platform specific package managers seem like the correct solution.

Perhaps something important is gained from integrating some subset of 1-5.  Perhaps the particular implementations of #1-5 are lacking in some manner that is not apparent. Perhaps we just need community acceptance for a particular version of each of these.

-Alex-






Michael T. Richter wrote:
On Mon, 2007-08-01 at 18:19 +0100, Sven Panne wrote: 
> For example, if I want to install Rails (ruby web-app framework), I just
> type:
>   gem install rails
> It's pretty slick.
    
  
How does this work with the native packaging mechanism on your platform 
(RPM, ...)? Does it work "behind it's back" (which would be bad)?

It doesn't.  It is its own Ruby-specific packaging mechanism.

Let's 
assume that "rails" needs "foo" and "bar" as well, which are not yet on your 
box. Does "gem install" transitively get/update all dependecies of "rails"?

Well rails needs dozens of libraries, seemingly, and it can be told to collect all dependencies.  (If it isn't told one way or another, it asks.)  This is true, however, iff the dependencies are all gems themselves.  If you need a third-party library installed that's not wrapped in a gem, you have to use your usual packaging system to get it.  (Being an Ubuntu user, I use aptitude.)

Overall, I like the gems approach.  The Ruby packages for debian-alikes are almost invariably out of date and building a lot of these Ruby enhancements is a pain in the posterior.  If I want a stable version of a given component, I'll use aptitude (or RPM or whatever) and live with it being out of date.  If I want the latest and greatest, however, I'll stick to the gems.  Since gems can be installed and deleted just like aptitude's packages can be (and just as cleanly) it really isn't that hard an approach.

-- 
Michael T. Richter
Email: ttmrichter@gmail.com, mtr1966@hotpop.com
MSN: ttmrichter@hotmail.com, mtr1966@hotmail.com; YIM: michael_richter_1966; AIM: YanJiahua1966; ICQ: 241960658; Jabber: mtr1966@jabber.cn

"[Blacks] ... are inferior to the whites in the endowments both of body and mind." --Thomas Jefferson 

_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe