is it a good idea to have HaskellForge? Ruby, Lua and some other languages have already adopted GForge, and I must say, those sites look *impressive*!!! any Ruby programmer on the list? can anyone provide an estimate of the amount of work involved? cheers, and long live the lambda revolution. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
uchchwhash:
is it a good idea to have HaskellForge?
Ruby, Lua and some other languages have already adopted GForge, and I must say, those sites look *impressive*!!!
Got some URLs for these?
any Ruby programmer on the list? can anyone provide an estimate of the amount of work involved?
cheers, and long live the lambda revolution.
The Haskell version is called 'hackage' and is a hot topic over on the libraries list at the moment. Expect developments soon! -- Don "Lambdas for all!" Stewart
On Jan 7, 2007, at 23:17 , Donald Bruce Stewart wrote:
uchchwhash:
is it a good idea to have HaskellForge?
Ruby, Lua and some other languages have already adopted GForge, and I must say, those sites look *impressive*!!!
Got some URLs for these?
http://rubyforge.org/ , for one. But I'd argue it's not really Hackage, so much as a pretty wrapper for darcs.haskell.org. (Gems is the Ruby equivalent of Cabal and Hackage.) -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
allbery:
On Jan 7, 2007, at 23:17 , Donald Bruce Stewart wrote:
uchchwhash:
is it a good idea to have HaskellForge?
Ruby, Lua and some other languages have already adopted GForge, and I must say, those sites look *impressive*!!!
Got some URLs for these?
http://rubyforge.org/ , for one. But I'd argue it's not really Hackage, so much as a pretty wrapper for darcs.haskell.org. (Gems is the Ruby equivalent of Cabal and Hackage.)
Ah right. So hosting + build systems + stats + blogs (apparently) I.e. cabal + hackage + planet.haskell + weekly news ;) -- Don
Hi
I.e. cabal + hackage + planet.haskell + weekly news ;)
Does hackage actually allow a user to setup a new darcs repo on a remote server? That's about the only thing lacking - for everything else people can just use code.google.com, which is way better than anything any Haskell hacker would ever have time to come up with. Thanks Neil
On 1/7/07, Brandon S. Allbery KF8NH
http://rubyforge.org/ , for one. But I'd argue it's not really Hackage, so much as a pretty wrapper for darcs.haskell.org. (Gems is the Ruby equivalent of Cabal and Hackage.)
I've been programming in Ruby for about 1.5 years, and rubyforge is one of the strong "features" of the community. It's a central place where libraries can be distributed easily to other ruby hackers. From my limited experience with Haskell (about 5 months), finding, installing, and using libraries is one of the bigger pains. For example, if I want to install Rails (ruby web-app framework), I just type: gem install rails It's pretty slick.
Am Montag, 8. Januar 2007 17:15 schrieb Justin Bailey:
[...] 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)? 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"? Cheers, S.
On 1/8/07, Sven Panne
Am Montag, 8. Januar 2007 17:15 schrieb Justin Bailey:
[...] 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)? 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"?
Gems is pretty self-contained - gems can depend on other gems, with a variety of versioning options. If you try to install a gem that depends on others, you will be asked if you wish to install those first (unless the correct versions are already present on your machine). I use Windows so there isn't any other packaging system for it to interact with.
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
On Tue, Jan 09, 2007 at 12:51:06 +0800, Michael T. Richter wrote: [..]
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.
Just out of curiousity, does 'gem' work with 'checkinstall'? /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus@therning.org Jabber: magnus.therning@gmail.com http://therning.org/magnus
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
I think people want something like CPAN. This implies a centralized "official" repository, somewhere that isn't going to go away, ever, because too many people would scream. It should probably be mirrored, too, like with cpan. Maybe darcs.haskell.org is ok for this roll already. Not sure. (Still a haskell nube.) Cheapo repo hosting is for projects where the owners don't feel secure enough, or don't want the responsibility, of committing to the "official" repo. Committing to the social repo gets you status, but it's work too because of maintenance, bug reports, etc. So, like with cpan, some will, some won't. Module chasing should carry on in the context of that repo. External dependency chasing -- like you need to install some c library... well, I'm not sure. Right everyone? -- View this message in context: http://www.nabble.com/HaskellForge--tf2935549.html#a8276650 Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.
tphyahoo wrote:
I think people want something like CPAN. This implies a centralized "official" repository
I agree. I think we also need a notion of a canonical standard package for each popular category. True, it is sometimes nice to have a lot of alternatives to choose from. And to be able to specify the resulting package dependencies. But other times that is not good. If you need to include a certain functionality in your program, sometimes the most important factors are that it is least likely to cause package conflicts for the widest possible audience, or that the widest possible audience will easily understand how it works, or that it will integrate well with a wide variety of other services. In a CPAN-like world that can be very difficult. -Yitz
Yitzchak Gale wrote:
tphyahoo wrote:
I think people want something like CPAN. This implies a centralized "official" repository
I agree.
I think we also need a notion of a canonical standard package for each popular category.
For some categories, it might be better to have a canonial standard *typeclass* and let various packages derive from that class. Cf. the Python DB-API (http://www.python.org/dev/peps/pep-0249/) and WSGI (http://www.python.org/dev/peps/pep-0333/).
On 2007-01-07, Imam Tashdid ul Alam
is it a good idea to have HaskellForge?
Ruby, Lua and some other languages have already adopted GForge, and I must say, those sites look *impressive*!!!
Have you looked at trac? I'm using it for about a dozen projects over on http://software.complete.org/. For instance, http://software.complete.org/missingh I looked at Savane and GForge, and both looks like they were overkill for what I wanted. They are both very invasive on the host system, requiring user accounts to be setup, hosts entries added, DNS control, all sorts of Apache tweaks, etc. You really need a dedicated OS install for them. And neither really seemed to be all that featureful, either. Wikis weren't a standard part of either, and forums were a deprecated part of one. The one thing they have over GForge is mailing list integration, but I just point people to haskell-cafe anyway. Plus: only trac has integration with darcs. It took some time to get trac setup and working the way I want to, with the right plugins, but once done, it's been happy. -- John
participants (13)
-
Alex Jacobson -
Brandon S. Allbery KF8NH -
dons＠cse.unsw.edu.au -
Imam Tashdid ul Alam -
John Goerzen -
Justin Bailey -
Magnus Therning -
Michael T. Richter -
Neil Mitchell -
Seth Gordon -
Sven Panne -
tphyahoo -
Yitzchak Gale