On Tue, Mar 15, 2005 at 09:11:07AM +0900, James Edward Gray II wrote:
> This is not meant as an attack. I'm asking an honest question, > hopefully of the RPA developers. Is the RPA still under active > development? It seems to have slipped off the public radar. (Or > perhaps it's just my radar.)
The port/package manager (rpa-base) and the incipient infrastructure (repository, VCS, wiki) are unsatisfactory under our (admittedly severe) criteria. They will undergo major restructuring. Had they been deemed adequate, RPA would have been proposed for widespread public consumption long ago, but it was in a testing phase for a reason.
As for
eric> Combining RPA and Gems is probably not going to be done during our eric> Codefest.
and
ben> Is there any chance you could start this process a little bit? Choose ben> some of the main features of RPA that are missing from RubyGems and find ben> a way of integrating them?
Comparing RubyGems to RPA is akin to assimilating rpm to FreeBSD. It doesn't really make that much sense. I understand that you mean one of (1) RubyGems (the installer) could take some features from rpa-base (2) RubyGems (the project) could grow in scope and try to reach some of the goals expressed by RPA (making it a sort of RPAlite?)
Regarding (1), some things like proper DATADIR support, installation into sitelibdir, transparent operation, compatibility with native tools, etc. are hardly doable in RubyGems due to some fundamental implementation choices.
I would really appreciate if Chad, Jim, Gavin, ..., clarified the situation. Especially since there have been some talks as of late about RubyGems replacing RAA altogether, RubyGems being the only repository for Ruby software, etc.
I'm looking forward to the results of this codefest. Happy hacking to the Seattle.rb brigade :) I'm very interested in the outcome of that event, for I don't really know how effective codefests can be in practice. Since I know the problem space ((re)packaging) and the concerned codebase (RubyGems) fairly well, I hope I'll be able to draw some conclusions.
//The port/package manager (rpa-base) and the incipient //infrastructure (repository, VCS, wiki) are unsatisfactory //under our (admittedly severe) criteria. They will undergo //major restructuring. Had they been deemed adequate, RPA would //have been proposed for widespread public consumption long //ago, but it was in a testing phase for a reason.
noble deed; but have you already addressed the common complaint of developers that rpa is not yet documented? It seems that they have difficulty creating their own rpas... They you have utilities for fast rpa generation?
yes, but gems is already being used/promoted (look at rails) by hundreds of developers. There must be something good in it.
//I would really appreciate if Chad, Jim, Gavin, ..., clarified //the situation. Especially since there have been some talks as //of late about RubyGems replacing RAA altogether, RubyGems //being the only repository for Ruby software, etc.
I would not concern myself about that. Forcing_ everyone to use gem is stupid (like forcing everyone to use rpm :). RAA should just be index. I still want to get pristine untouched code of the author; and tar w setup of the humble aoki is still the way for me. No politics.
RPA is great software. I never had an issue or bug encountered. If you build it quick for everyone's consumption, they will use it. Time is moving fast, and many people cannot wait...
> noble deed; but have you already addressed the common complaint of > developers that rpa is not yet documented? It seems that they have > difficulty creating their own rpas... They you have utilities for fast rpa > generation?
If you need help, please ask. #RPA irc.freenode.net, open 24/7/365
> yes, but gems is already being used/promoted (look at rails) by hundreds of > developers. There must be something good in it.
You can justify many things in the universe with this kind of reasoning.
(the existence of Saskwatch, UFOs, Elvis still alive, to name a few things witnessed by hundreds of developers)
> I would not concern myself about that. Forcing_ everyone to use gem is > stupid (like forcing everyone to use rpm :). RAA should just be index. I > still want to get pristine untouched code of the author; and tar w setup of > the humble aoki is still the way for me. No politics. > RPA is great software. I never had an issue or bug encountered. If you build > it quick for everyone's consumption, they will use it. Time is moving fast, > and many people cannot wait...
On Tue, 15 Mar 2005 10:44:36 +0900, Mauricio Fernández
<batsman....@yahoo.com> wrote: > Comparing RubyGems to RPA is akin to assimilating rpm to FreeBSD. > It doesn't really make that much sense. I understand that you mean > one of (1) RubyGems (the installer) could take some features from > rpa-base (2) RubyGems (the project) could grow in scope and try to > reach some of the goals expressed by RPA (making it a sort of > RPAlite?) > Regarding (1), some things like proper DATADIR support, > installation into sitelibdir, transparent operation, compatibility > with native tools, etc. are hardly doable in RubyGems due to some > fundamental implementation choices.
Sorry, Mauricio, but I disagree. Nothing about RubyGems *prevents* any of the above. Nothing. The gemspec can be translated into "native" tools, and the RPA-base layer could be implemented on top of RubyGems as a platform (e.g., making the sitelibdir and DATADIR support work), and since Matz seems to have indicated that RubyGems will become part of the core when it's ready, then it will work transparently.
I have further indicated in several places how RPA "version-sets" could be done with RubyGems -- and the latest version of RubyGems appears to include something that supports this, although it does require some additional code at the moment.
Again, this isn't really true. There isn't anything currently available aside from the project description:
RubyGems is the Ruby standard for publishing and managing third party libraries.
It is *intended* to be the Ruby standard for publishing and managing third party libraries, certainly. Much as there's a standard layout and Makefile form for Perl that makes things Just Work, so RubyGems is intended to be, while solving certain real problems.
> I would really appreciate if Chad, Jim, Gavin, ..., clarified the > situation. Especially since there have been some talks as of late > about RubyGems replacing RAA altogether, RubyGems being the only > repository for Ruby software, etc.
Um. No. RAA isn't going away. That HAS been made very clear. RubyGems may become the preferred way of packaging projects, with a RubyGems site and/or RubyForge becoming a preferred location for distribution -- but not precluding alternative distribution sites.
> Matz seems to have indicated that RubyGems > will become part of the core when it's ready, then it will work > transparently.
This ISN'T true. And I quote matz here:
"I think there's need for both a packaging "system" and a package repository. I wish for a sound cooperation of the former (rubygems?) and the latter (rpa?). I'd happy to merge the packaging system (with which both teams can agree) in the standard Ruby."
Edited for easy reading: (uppercase are RFC-style emphasis, not irc-style yelling)
"I wish for a sound cooperation of RubyGems and RPA. I'd be happy to merge the packaging system (with which BOTH TEAMS CAN AGREE) in the standard Ruby"
Those who want to read carefully without skipping words will understand: --------------------------------------------------------------------------- -----------------------------
Matz HAS NOT indicated RubyGems will become part of the core.
Matz HAS indicated BOTH TEAMS will have to agree before ANYTHING gets in the standard Ruby.
Another flawed misconception: -------------------------------------------- The language has to be modified to accomodate packaging
No decent programming language I have seen on earth has had to be modified in order to accomodate a packaging system, (whether RPA or Rubygems is beyond the point) which is ultimately an application level concern.
Ideally, the Ruby implementation by Matz COULD, (but doesn't necessarily HAVE TO) implement the needed feature as an extension to the readily available 'require' statement.
The consequences of something like a pervasive require_gem as part of the standard could stay with us for too many years to come. Think of Ruby compilers dealing with that.
Finally as Matz has clearly said:
"I wish for a sound COOPERATION of RubyGems and RPA."
This doesn't mean RubyGems has to absorb RPA, nor RPA absorb RubyGems, nor any of the other misconceptions that have been widely advertised. Much less the horrible thought of butchering either project, as someone has cluelessly said in previous threads. (something clearly neither the RubyGems team nor the RPA team want)
from the dictionary:
TO COOPERATE: -------------------------- 1. To work or act together toward a common end or purpose. 2. To acquiesce willingly; be compliant 3. To form an association for common, usually economic, benefit
On Tue, Mar 15, 2005 at 11:37:31AM +0900, "Peña, Botp" wrote: > Mauricio Fernández [mailto:batsman....@yahoo.com] wrote:
> //The port/package manager (rpa-base) and the incipient > //infrastructure (repository, VCS, wiki) are unsatisfactory > //under our (admittedly severe) criteria. They will undergo > //major restructuring. Had they been deemed adequate, RPA would > //have been proposed for widespread public consumption long > //ago, but it was in a testing phase for a reason.
> noble deed; but have you already addressed the common complaint of > developers that rpa is not yet documented? It seems that they have > difficulty creating their own rpas... They you have utilities for fast rpa > generation?
rpa-base in its current state will probably not be documented for mass consumption because it is going to change a lot. Asking you to use a tool we are not entirely satisfied with :) would not be very reasonable. There's a heavy responsibility associated to saying "plz use this to package your sw."; we don't want people to have to package it twice due to some incompatible change, and, as I said before, rpa-base *must* change because it is not really satisfactory yet.
We've learned quite a bit from the first testing phase, and I think we now know the requirements well enough to create a tool that will satisfy RPA's requirements and incidentally prove useful to other people. When the time comes, it will be well-documented and offered for mass consumption.
> yes, but gems is already being used/promoted (look at rails) by hundreds of > developers. There must be something good in it.
Definitely. RubyGems is, well, *the* primary distribution format for Rails. It matches Rails' philosophy very well.
Note that I'm not discussing the goodness of RubyGems, but... [read below]
> //I would really appreciate if Chad, Jim, Gavin, ..., clarified > //the situation. Especially since there have been some talks as > //of late about RubyGems replacing RAA altogether, RubyGems > //being the only repository for Ruby software, etc.
.. rather asking RubyGems' developers to write a document explaining their goals. Not really for me, mind you (I know RubyGems fairly well, and I've talked with the RubyGems developers quite often), but for people like those who began this thread.
> I would not concern myself about that. Forcing_ everyone to use gem is > stupid (like forcing everyone to use rpm :). RAA should just be index.
Yes, I know that that (replacing RAA altogether) is not happening, but seemingly not everyone out there does. The RubyGems team could prevent further waste of time and BW by explaining this in a manifesto, I believe.
> I still want to get pristine untouched code of the author; and tar w setup of > the humble aoki is still the way for me. No politics.
Yes, Aoki's setup.rb is still the best solution (better than rpa-base too) in many cases. I once proposed it as a repackager-neutral standard but the current trend seems to be gem-only releases.
> RPA is great software. I never had an issue or bug encountered. If you build
[BTW I remember your still unsatisfied feature request and can promise it will be present in the next phase :)]
> it quick for everyone's consumption, they will use it. Time is moving fast, > and many people cannot wait...
Thank you for your kinds words. I know that many people would like RPA to happen quicker :)... I can confidently say that RPA will develop faster in the near future, and the experience gathered last year will be very helpful. I believe the situation is mature now; the real repository is not very far away, but we still have quite some work to do.
On Tue, Mar 15, 2005 at 01:15:17PM +0900, Austin Ziegler wrote: > > Regarding (1), some things like proper DATADIR support, > > installation into sitelibdir, transparent operation, compatibility > > with native tools, etc. are hardly doable in RubyGems due to some > > fundamental implementation choices.
> Sorry, Mauricio, but I disagree. Nothing about RubyGems *prevents* > any of the above. Nothing.
It makes these things more difficult ("hardly doable", maybe I should have phrased it as "hard to do"), to the point that we would have to work around some of RubyGems' limitations, relative to the problem we are trying to solve. This is one of the reasons why there's no net gain for us in using RubyGems.
I must say that I do not really understand why so much pressure is put on us to dump a custom-made tool, crafted to suit our needs, which does not compete against RubyGems, in favor of the latter. In global terms, the existence of rpa-base is positive for RubyGems to the extend that the latter has reused code from the former.
I don't know why the very existence of RPA's technology, which is not being imposed on anyone, and is there to fit a particular role, must be constantly justified. There are reasons to have it; the code works for us and will work better.
> The gemspec can be translated into "native" tools, and the RPA-base > layer could be implemented on top of RubyGems as a platform (e.g., > making the sitelibdir and DATADIR support work)
That would involve bypassing the services provided by the RubyGems sublayer and operating directly on the destination FS. The primitives offered by RubyGems are not sufficient. It wouldn't make that much sense to have the fundamental operations performed by such a rpa-base layer far exceed those offered by the "platform" the latter is built on.
As for the conversion of the gemspec, note that this requires access to the pristine sources. The gemification process is not idempotent, which is quite unfortunate since RubyGems is meant to be the standard *upstream* format. Besides, RubyGems packages cannot be converted into satisfactory native packages in general; there's too much variance and the modifications upstream has to do to make software work with RubyGems get in the way.
> and since Matz seems to have indicated that RubyGems > will become part of the core when it's ready, then it will work > transparently.
Some things (DATADIR, etc) wouldn't work transparently as of today even if RubyGems were integrated into the std. library.
AFAIK matz's latest take on this is
I'd happy to merge the packaging system (with which both teams can agree) in the standard Ruby.
That's fine; maybe some of our ideas can help make RubyGems better.
But what gets into the standard library is not really relevant for the issue being discussed. I think it is not excessive to claim the right to use the best tool for the goals we have decided to strive for. Not surprisingly, we think that the best tool can be one designed specifically to satisfy those needs.
The alternative would be pestering the RubyGems team until RubyGems does things the way RPA needs them done. I believe that wouldn't be any better, and I think most people would agree.
> I have further indicated in several places how RPA "version-sets" > could be done with RubyGems -- and the latest version of RubyGems > appears to include something that supports this, although it does > require some additional code at the moment.
I had that idea ~ 1 year ago (it was considered while evaluating RubyGems, before the development of rpa-base began) but rejected it because several problems would still remain.
> Again, this isn't really true. There isn't anything currently > available aside from the project description:
> RubyGems is the Ruby standard for publishing and managing third > party libraries.
How is that equivalent to a manifesto? :-)
> > I would really appreciate if Chad, Jim, Gavin, ..., clarified the > > situation. Especially since there have been some talks as of late > > about RubyGems replacing RAA altogether, RubyGems being the only > > repository for Ruby software, etc.
> Um. No. RAA isn't going away. That HAS been made very clear. > RubyGems may become the preferred way of packaging projects, with a > RubyGems site and/or RubyForge becoming a preferred location for > distribution -- but not precluding alternative distribution sites.
Austin, I know RubyGems quite well, better than most of its users actually (better than some of the developers too, there's more code of mine in RubyGems after all hehe :). *I* know that RAA is not going away.
But I think the RubyGems team could prevent further pointless discussion in ruby-talk by specifying their goals in something comparable to the RPA manifesto (which the above one-sentence description is *not*).
The talks about RubyGems replacing RAA, etc, didn't originate in the RubyGems team but rather in groups of users. So it's up to the RubyGems team to make sure that people understand what RubyGems is and what it is not meant to be.
I'm asking them to write a manifesto so we have something to point at instead of having to write lengthy explanations on ruby-talk every time somebody starts such a "RubyGems vs RPA" or "Combining RubyGems and RPA" or "Dump RAA, use Rubyforge, dump RPA, use RubyGems" thread.
> 1) Having a command to remove all, but the most recent version of > installed gems (I had to clean up about 10 versions of Rails, > ActiveRecord and ActionPack the other day)
> 2) Having a "show" command, where there would be a detailed explanation > of what a particular gem does ("search" could also search that > description), a URL, an author email, etc.
gem spec will show the gem specification, which contains all the metadata we have on a gem. But the output isn't pretty. Some command to give that information in a "pretty" format would be nice.
> 3) Already mentionned by Gabriele, a cute progress bar (using > progressbar available in RubyGems)
If so, should be tied into the generic Gems UI protocol(not a hard problem).
-- -- Jim Weirich j...@weirichhouse.org http://onestepback.org ----------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
I'm not sure I completely understand the analogy comparing RubyGems and RPA to rpm vs. FreeBSD. I understand the basics however. RPA doesn't care too much about the package format, it's more focused on the process, and making sure that there are consistent, documented libraries that are production-ready (that's what your manifesto says anyhow). This is like how the FreeBSD ports system works (or so I understand). The packages are audited, repositories are maintained, etc. RubyGems on the other hand *seems* to be an attempt to create a package format, a repository and a basic package manager, with new features added as they become necessary. This is like the rpm package format and the rpm commandline tool. On the other hand, there's no attempt made to see if a given foo.rpm is any good.
There are certainly areas of overlap -- the package management tool, the repository, and the specific packaging requirements. These are the things that an end-user would interact with. Given that, it's completely understandable that people see them as competing projects. It just seems like RPA has a lot more depth in what it's trying to achieve.
I think the reason that RubyGems has a bigger "head of steam" is that it's easier for people to wrap their heads around it. All you have to do is convert your package to a Gem and get it in the repository. For RPA there seems to be a much higher barrier to entry, and (speaking as a developer) I don't exactly understand what I need to do.
I may be wrong, but it seems to me that there's something missing from *both* projects: stable vs. unstable.
In RPA it seems like *everything* is stable. That's good, but it's also limiting. I haven't used FreeBSD but I use Gentoo and Debian, and although the "stable" branches of both of those distributions are full of qualified, stable packages, they also have an unstable area, where the packages are in the appropriate format, but other than that, no real checking is done. I don't know about other people, but if I could only use the stable packages, I'd have a lot of trouble.
RubyGems is almost the opposite. In RubyGems *nothing* is stable, because there is no concept of stability. As DHH mentioned, you can use different gem repository URLs to have stable vs. unstable gems, however that's not a real solution. Once a gem is installed, as far as I know the system has no way of knowing whether it was tagged as stable or unstable. As far as I know, you can't track the 'stable' and 'unstable' gems separately.
The more I understand about RPA, the more useful I think it could be. I regret not understanding it better before. If the RPA and RubyGems efforts were combined, I could see RPA adding features to support RubyGems... but at this point I don't see how the opposite would work. It seems that because RubyGems was never planned as a system with audited packages, guaranteed-good documentation, multiple package formats, etc. it would be really hard to modify it to include those things.
It is much easier for me to see RPA being able to deliver packages to various distributions as .debs .rpms .tar.gzs, ebuilds and even gems. I think that's a really important feature of a packaging system.
So here's a question for you:
As I understand it, RubyGems is:
1) a package format 2) a repository 3) a package management tool
and essentially
4) a relatively easy way for developers to throw together a possibly unstable, but possibly really useful library and put it somewhere where people can get to it
RPA has all of the above except number 4, I believe. Could RPA also provide that?
"Peña, Botp" <b...@delmonte-phil.com> writes: > //I would really appreciate if Chad, Jim, Gavin, ..., clarified > //the situation. Especially since there have been some talks as > //of late about RubyGems replacing RAA altogether, RubyGems > //being the only repository for Ruby software, etc.
> I would not concern myself about that. Forcing_ everyone to use gem is > stupid (like forcing everyone to use rpm :).
I can only wholeheartedly agree with that. Dear rubyists, please assure that your software will run *without RubyGems* installed. This means, e.g. that Rakefiles rescue from LoadErrors resulting from requiring rubygems. That you cannot generate gems then is clear, but please at least make the other, gem independent stuff work.
Also, don't do gem only releases.
> RPA is great software. I never had an issue or bug encountered. If you build > it quick for everyone's consumption, they will use it. Time is moving fast, > and many people cannot wait...
> I must say that I do not really understand why so much pressure is put > on us to dump a custom-made tool, crafted to suit our needs, which does > not compete against RubyGems, in favor of the latter.
Agreed. I don't care if you dump rpa-base or keep it at this point. There's a lot of mailing list noise about it, but other than that there is no real negative effect of having the two formats.
> > and since Matz seems to have indicated that RubyGems > > will become part of the core when it's ready, then it will work > > transparently.
> AFAIK matz's latest take on this is
> I'd happy to merge the packaging system (with > which both teams can agree) in the standard Ruby.
> That's fine; maybe some of our ideas can help make RubyGems better.
They already have. But it seems to me that Matz feels we need to converge on a common format (between RubyGems and RPA). We don't. I propose that we already "agree" to the necessary level. We have totally different goals, with some confusing implementation overlap.
> How is that equivalent to a manifesto? :-)
I refuse to ever write anything called a "manifesto", nor do I think there are many people confused by the fact we haven't written one. Here's the purpose of RubyGems (my take on it):
RubyGems is: 1. A package format for Ruby libraries and applications. 2. A system for managing installation of such packages from both local and remote sources. 3. A "master source"/repository for such packages. 4. Intended to be Ruby's standard for package creation and distribution.
Ask more questions if you need more clarification, and I'll add another bullet point or two.
> The talks about RubyGems replacing RAA, etc, didn't originate in the > RubyGems team but rather in groups of users. So it's up to the RubyGems > team to make sure that people understand what RubyGems is and what it is > not meant to be.
People will talk. That's always the case. There are always going to be people coming into ruby-talk and trying to make various aspects of our community and technologies into something they are not. Everyone has an opinion, and talk is cheap. For example, Ruby isn't statically typed, and no matter how much conversation goes on about this, people still bring it up.
> On Mar 14, 2005, at 12:23 PM, Ben Giddings wrote: >> Eric Hodel wrote: >>> Combining RPA and Gems is probably not going to be done during our >>> Codefest. >> Is there any chance you could start this process a little bit? > no
Lemme clarify a bit more.
Everyone STFU about RPA vs Gems. It is completely and 100% OT to this thread. We were mining for data and you guys introduced pure noise.
Just for total clarity, here is the original email:
> Seattle.rb will be hosting a RubyGems cleanup and enhancement codefest!
> We would like to solicit your ideas on what you want to see cleaned up > or enhanced in RubyGems.
> For our Codefest we do not plan on making large changes to the way > RubyGems works. One thing we would like to focus on is making the gem > command more friendly when you hit ^C, for example.
> Combining RPA and Gems is probably not going to be done during our > Codefest.
We'd like to show up w/ a prioritized list of things we'd like to do and maybe even some already failing unit tests so we can be on task from the very beginning. Instead, we are weeding through a bunch of dogmatic crap that we didn't ask for and are not much closer to having said list. I've flagged a couple of email for ideas, but they are a vast minority thus-far.
P.S. That goes for writing a whole GUI frontend as well. We are meeting for ONE WEEKEND.
On Wed, 16 Mar 2005 04:48:49 +0900, Ryan Davis <ry...@zenspider.com> wrote:
> On Mar 14, 2005, at 9:29 PM, Ryan Davis wrote:
> > On Mar 14, 2005, at 12:23 PM, Ben Giddings wrote: > >> Eric Hodel wrote: > >>> Combining RPA and Gems is probably not going to be done during our > >>> Codefest. > >> Is there any chance you could start this process a little bit? > > no
> Lemme clarify a bit more.
> Everyone STFU about RPA vs Gems. It is completely and 100% OT to this > thread. We were mining for data and you guys introduced pure noise.
> Just for total clarity, here is the original email:
> > Seattle.rb will be hosting a RubyGems cleanup and enhancement codefest!
> > We would like to solicit your ideas on what you want to see cleaned up > > or enhanced in RubyGems.
> > For our Codefest we do not plan on making large changes to the way > > RubyGems works. One thing we would like to focus on is making the gem > > command more friendly when you hit ^C, for example.
> > Combining RPA and Gems is probably not going to be done during our > > Codefest.
> We'd like to show up w/ a prioritized list of things we'd like to do > and maybe even some already failing unit tests so we can be on task > from the very beginning. Instead, we are weeding through a bunch of > dogmatic crap that we didn't ask for and are not much closer to having > said list. I've flagged a couple of email for ideas, but they are a > vast minority thus-far.
> P.S. That goes for writing a whole GUI frontend as well. We are meeting > for ONE WEEKEND.
I'm confused. _What_ goes for writing a whole GUI frontend?
You're going to write a frontend for 'gems'? The _first_ release should be entirely possible in one weekend with a couple of good developers.
I'm curious so that I know if I should bother to start thinking about it on my own or not...
.. on the other hand...
If you're telling me to STFU about discussing the fact that I think a GUI for the whole 'gems' concept would be an enhancement (since you asked for our ideas on possible enhancements), then I'm really confused...
I guess I just think that STFU is pretty harsh for a list like 'ruby-talk'... and as a possible point of interest: I personally decided to try and live without RPA since one of the 'developers' had such bad PR. I'd really hate to see 'gems' go the same route.
Thanks for contributing! I hope I can contribute too.
On Tue, 15 Mar 2005 22:55:42 +0900, Martin DeMello
<martindeme...@yahoo.com> wrote: > Richard Lyman <lym...@gmail.com> wrote: > > synaptic), no method of 'making packages available' is going to appeal > > to the general populous (sp?) until then... anyway...
On Wed, 16 Mar 2005 07:33:11 +0900, Richard Lyman <lym...@gmail.com> wrote: > If you're telling me to STFU about discussing the fact that I think a > GUI for the whole 'gems' concept would be an enhancement (since you > asked for our ideas on possible enhancements), then I'm really > confused...
I think Ryan is just asking everyone, in his own sweet way, to "STFU" about comparisons between RPA and RubyGems because *that* discussion is completely off-topic for the originally stated purpose of *this* thread (namely, Eric's question: "What you want to see cleaned up or enhanced in RubyGems?").
I don't believe that anyone is opposed to the development of a GUI front-end to RubyGems, but it may be (in Ryan's estimation) too large of a project for the guys to try to tackle in one weekend, considering all of the other possible "cleanups" that likely need to be done.
> -----Original Message----- > From: Lyle Johnson [mailto:lyle.john...@gmail.com]
<snip>
> I don't believe that anyone is opposed to the development of > a GUI front-end to RubyGems, but it may be (in Ryan's > estimation) too large of a project for the guys to try to > tackle in one weekend, considering all of the other possible > "cleanups" that likely need to be done.
Switching gears again, what benefit does a standalone GUI provide over a web interface to the gem server? Or is it just too rich for a web UI?
On Wed, 16 Mar 2005 07:59:42 +0900, Berger, Daniel
<Daniel.Ber...@qwest.com> wrote: > Switching gears again, what benefit does a standalone GUI provide over a > web interface to the gem server? Or is it just too rich for a web UI?
The UI should manage local gems too. A UI based on the server would have to know about local gems, which would make implementaion dfficult :(
I know there are a lot of people who don't want to talk about RPA and RubyGems, perhaps you included. Matz does seem to feel that there is some benefit in combining the two, and I happen to agree. On the other hand, they aren't my projects, and I don't even fully understand them. Although they are different in a lot of ways, they do share enough that it seems there is an unnecessary duplication of effort. I think it would be really helpful if we could clear up some points that still confuse people about the two projects.
If you'd prefer not to talk about it, please feel free to tell me to STFU (though nicer language would of course be appreciated). If not, please read on.
I'm not sure I completely understand the analogy comparing RubyGems and RPA to rpm vs. FreeBSD. I understand the basics however. RPA doesn't care too much about the package format, it's more focused on the process, and making sure that there are consistent, documented libraries that are production-ready (that's what your manifesto says anyhow). This is like how the FreeBSD ports system works (or so I understand). The packages are audited, repositories are maintained, etc. RubyGems on the other hand *seems* to be an attempt to create a package format, a repository and a basic package manager, with new features added as they become necessary. This is like the rpm package format and the rpm commandline tool. On the other hand, there's no attempt made to see if a given foo.rpm is any good.
There are certainly areas of overlap -- the package management tool, the repository, and the specific packaging requirements. These are the things that an end-user would interact with. Given that, it's completely understandable that people see them as competing projects. It just seems like RPA has a lot more depth in what it's trying to achieve.
I think the reason that RubyGems has a bigger "head of steam" is that it's easier for people to wrap their heads around it. All you have to do is convert your package to a Gem and get it in the repository. For RPA there seems to be a much higher barrier to entry, and (speaking as a developer) I don't exactly understand what I need to do.
I may be wrong, but it seems to me that there's something missing from *both* projects: stable vs. unstable.
In RPA it seems like *everything* is stable. That's good, but it's also limiting. I haven't used FreeBSD but I use Gentoo and Debian, and although the "stable" branches of both of those distributions are full of qualified, stable packages, they also have an unstable area, where the packages are in the appropriate format, but other than that, no real checking is done. I don't know about other people, but if I could only use the stable packages, I'd have a lot of trouble.
RubyGems is almost the opposite. In RubyGems *nothing* is stable, because there is no concept of stability. As DHH mentioned, you can use different gem repository URLs to have stable vs. unstable gems, however that's not a real solution. Once a gem is installed, as far as I know the system has no way of knowing whether it was tagged as stable or unstable. As far as I know, you can't track the 'stable' and 'unstable' gems separately.
The more I understand about RPA, the more useful I think it could be. I regret not understanding it better before. If the RPA and RubyGems efforts were combined, I could see RPA adding features to support RubyGems... but at this point I don't see how the opposite would work. It seems that because RubyGems was never planned as a system with audited packages, guaranteed-good documentation, multiple package formats, etc. it would be really hard to modify it to include those things.
It is much easier for me to see RPA being able to deliver packages to various distributions as .debs .rpms .tar.gzs, ebuilds and even gems. I think that's a really important feature of a packaging system.
So here's a question for the RPA developers:
As I understand it, RubyGems is:
1) a package format 2) a repository 3) a package management tool
and essentially
4) a relatively easy way for developers to throw together a possibly unstable, but possibly really useful library and put it somewhere where people can get to it
I think that's a great service, and something that was desperately needed. Before RubyGems there were no common repositories, no common package formats, no easy tools for installing them, etc. It's really cool that there are now ways of installing programs via gems, and it looks like the RubyGems people are really responsive to feature requests, and are constantly trying to improve their offering. On the other hand, some of the RPA goals (audited packages, documentation, a good upstream format, etc.) seem to be things that are not major concerns to the RubyGems developers.
I believe RPA has all of the above except number 4. As I've said, it also seems to have a lot more besides. Could RPA also provide that?
I'm all for using the best tool for the job, but somebody had a tool to hammer nails into wood, and somebody else had a tool to remove nails from wood. Wouldn't it be amazing if those two tools could be combined into one uber-tool?
On Tue, 15 Mar 2005 16:55:18 -0600, Lyle Johnson <lyle.john...@gmail.com> wrote: > On Wed, 16 Mar 2005 07:33:11 +0900, Richard Lyman <lym...@gmail.com> wrote:
> > If you're telling me to STFU about discussing the fact that I think a > > GUI for the whole 'gems' concept would be an enhancement (since you > > asked for our ideas on possible enhancements), then I'm really > > confused...
> I think Ryan is just asking everyone, in his own sweet way, to "STFU" > about comparisons between RPA and RubyGems because *that* discussion > is completely off-topic for the originally stated purpose of *this* > thread (namely, Eric's question: "What you want to see cleaned up or > enhanced in RubyGems?").
> I don't believe that anyone is opposed to the development of a GUI > front-end to RubyGems, but it may be (in Ryan's estimation) too large > of a project for the guys to try to tackle in one weekend, considering > all of the other possible "cleanups" that likely need to be done.
> On Wed, 16 Mar 2005 04:48:49 +0900, Ryan Davis <ry...@zenspider.com> > wrote:
>> We'd like to show up w/ a prioritized list of things we'd like to do >> and maybe even some already failing unit tests so we can be on task >> from the very beginning. Instead, we are weeding through a bunch of >> dogmatic crap that we didn't ask for and are not much closer to having >> said list. I've flagged a couple of email for ideas, but they are a >> vast minority thus-far.
>> P.S. That goes for writing a whole GUI frontend as well. We are >> meeting >> for ONE WEEKEND.
> I'm confused. _What_ goes for writing a whole GUI frontend?
Not going to happen.
> You're going to write a frontend for 'gems'?
No.
> The _first_ release > should be entirely possible in one weekend with a couple of good > developers.
Exactly. The Codefest Grant is enough for one weekend, so what's the purpose of spending money on us if what we develop is unlikely to be maintained or finished? (I'm not terribly interested in maintaining it, and I'm certainly not interested in GUI toolkit headaches either.)
I'd much rather see the Codefest Grant money put to a use that will have the greatest benefit to Ruby, and a GUI only falls under the "ooh! shiny!" category for me.
Things like behaving nicely to ^C or a command to remove old gems are much more beneficial and I think the community will get more value for their donated dollars. We're looking for the rough edges and dull surfaces to sand down and polish. (Yeah, I'm going to be spending your money, so I don't want to be producing stillborn projects.)
The idea is to pull off a huge success so we (the community) can point to something and say "look what your donated dollars bought!" This way more dollars will be donated which allows larger, longer projects to be funded.
<bg-rubyt...@infofiend.com> wrote: > RPA doesn't > care too much about the package format, it's more focused on the > process, and making sure that there are consistent, documented libraries > that are production-ready (that's what your manifesto says anyhow). > This is like how the FreeBSD ports system works (or so I understand). > The packages are audited, repositories are maintained, etc. RubyGems on > the other hand *seems* to be an attempt to create a package format, a > repository and a basic package manager, with new features added as they > become necessary. This is like the rpm package format and the rpm > commandline tool. On the other hand, there's no attempt made to see if > a given foo.rpm is any good.
Both sides have the *same* goal: Get code from the writers to the users.
Here we have RubyGems as "Worse" and RPA as the "Right Thing"... someone just needs to point out that they are trying to do the same thing: get the best Ruby code out to the people who want it. It is just that one side talks about manifestos and the other talks about purpose, beyond that they have the same goal.
On Wed, 16 Mar 2005 10:00:55 +0900, Eric Hodel <drbr...@segment7.net> wrote: > On 15 Mar 2005, at 14:33, Richard Lyman wrote:
> > On Wed, 16 Mar 2005 04:48:49 +0900, Ryan Davis <ry...@zenspider.com> > > wrote:
> >> We'd like to show up w/ a prioritized list of things we'd like to do > >> and maybe even some already failing unit tests so we can be on task > >> from the very beginning. Instead, we are weeding through a bunch of > >> dogmatic crap that we didn't ask for and are not much closer to having > >> said list. I've flagged a couple of email for ideas, but they are a > >> vast minority thus-far.
> >> P.S. That goes for writing a whole GUI frontend as well. We are > >> meeting > >> for ONE WEEKEND.
> > I'm confused. _What_ goes for writing a whole GUI frontend?
> Not going to happen.
> > You're going to write a frontend for 'gems'?
> No.
> > The _first_ release > > should be entirely possible in one weekend with a couple of good > > developers.
> Exactly. The Codefest Grant is enough for one weekend, so what's the > purpose of spending money on us if what we develop is unlikely to be > maintained or finished? (I'm not terribly interested in maintaining > it, and I'm certainly not interested in GUI toolkit headaches either.)
> I'd much rather see the Codefest Grant money put to a use that will > have the greatest benefit to Ruby, and a GUI only falls under the "ooh! > shiny!" category for me.
> Things like behaving nicely to ^C or a command to remove old gems are > much more beneficial and I think the community will get more value for > their donated dollars. We're looking for the rough edges and dull > surfaces to sand down and polish. (Yeah, I'm going to be spending your > money, so I don't want to be producing stillborn projects.)
> The idea is to pull off a huge success so we (the community) can point > to something and say "look what your donated dollars bought!" This way > more dollars will be donated which allows larger, longer projects to be > funded.
|
