alex at alexjacobson.com
Wed Jan 10 16:29:19 EST 2007
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
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
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
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.
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.
>> 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 at gmail.com, mtr1966 at hotpop.com
> /MSN:/ ttmrichter at hotmail.com, mtr1966 at hotmail.com; /YIM:/
> michael_richter_1966; /AIM:/ YanJiahua1966; /ICQ:/ 241960658;
> /Jabber:/ mtr1966 at jabber.cn
> /"[Blacks] ... are inferior to the whites in the endowments both of
> body and mind."/ *--Thomas Jefferson*
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe