Codefest Grant - RubyGems cleanup and enhancement
Eric Hodel
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.
--
Eric Hodel - drb...@segment7.net - http://segment7.net
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04
Curt Hibbs
>
> 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.
This is probably not feasible, but I'll throw it out there anyway -- I'd
like to see a GUI front-end to RubyGems... a RubyGems browser of sorts. Rich
Kilmer started on one, but I don't think it got finished (if it did, I would
already have it in the One-Click Ruby Installer).
Curt
James Britt
>
> This is probably not feasible, but I'll throw it out there anyway -- I'd
> like to see a GUI front-end to RubyGems... a RubyGems browser of sorts. Rich
> Kilmer started on one, but I don't think it got finished (if it did, I would
> already have it in the One-Click Ruby Installer).
Isn't that what RubySlippers is?
James
Curt Hibbs
Have you tried it? I would call it a primitive web front-end, and pretty
clunky at that.
What I want is something like a news reader, or windows file explorer. A
desktop GUI with a tree control on the left and a detail panel of sorts on
the right. With the ability to mount and browse multiple repositories as
well as your installed gems.
Curt
gabriele renzi
> 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.
definitely, ATM, rubygems does not feel "fault tolerant".
One little thing I'd appreciate is some kind of feedback for the user
like a progress bar both in downloading and upgrading cache.
And i would greatly appreciate speed, both in the way "gem" works and in
how the require thing work.
Oh, and and it would be cool to be able to use a .gem file the way a
.jar is used in java (but this would require using zip instead of gzip,
AFAICT).
> Combining RPA and Gems is probably not going to be done during our
> Codefest.
:)
James Britt
> James Britt wrote:
>
>>Curt Hibbs wrote:
>>
>>
>>>This is probably not feasible, but I'll throw it out there anyway -- I'd
>>>like to see a GUI front-end to RubyGems... a RubyGems browser
>>
>>of sorts. Rich
>>
>>>Kilmer started on one, but I don't think it got finished (if it
>>
>>did, I would
>>
>>>already have it in the One-Click Ruby Installer).
>>
>>
>>Isn't that what RubySlippers is?
>
>
> Have you tried it? I would call it a primitive web front-end, and pretty
> clunky at that.
I've used it, and it's not bad, but not the native-OS app I would prefer.
James
Richard Lyman
> Eric Hodel wrote:
> >
> > 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.
>
> like to see a GUI front-end to RubyGems... a RubyGems browser of sorts. Rich
> Kilmer started on one, but I don't think it got finished (if it did, I would
> already have it in the One-Click Ruby Installer).
>
> Curt
>
Yeah - I made a quick-n-dirty mockup that I gave Rich Kilmer and fully
expected pretty much everything to be redone, but I haven't seen
anything yet. For that matter, I haven't heard too much from him on
this list recently... being busy can be good though...
I really feel that until we have a _simple to use_ GUI (something like
synaptic), no method of 'making packages available' is going to appeal
to the general populous (sp?) until then... anyway...
I have no idea where my little mockup went, but it only took an hour
or so to do, so if someone wanted to, it wouldn't take them long to do
their own over again.
-Rich
Curt Hibbs
>
> On Sat, 12 Mar 2005 14:07:19 +0900, Curt Hibbs <cu...@hibbs.com> wrote:
> > Eric Hodel wrote:
> > >
> > > 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.
> >
> > This is probably not feasible, but I'll throw it out there anyway -- I'd
> > like to see a GUI front-end to RubyGems... a RubyGems browser
> of sorts. Rich
> > Kilmer started on one, but I don't think it got finished (if it
> did, I would
> > already have it in the One-Click Ruby Installer).
> >
> > Curt
> >
>
> Yeah - I made a quick-n-dirty mockup that I gave Rich Kilmer and fully
> expected pretty much everything to be redone, but I haven't seen
> anything yet. For that matter, I haven't heard too much from him on
> this list recently... being busy can be good though...
>
> I really feel that until we have a _simple to use_ GUI (something like
> synaptic), no method of 'making packages available' is going to appeal
> to the general populous (sp?) until then... anyway...
I completely agree. That's why I'm *very* interested in getting a GUI
front-end to RubyGems into the One-Click installer, and on Windows and the
upcoming installer for OSX.
> I have no idea where my little mockup went, but it only took an hour
> or so to do, so if someone wanted to, it wouldn't take them long to do
> their own over again.
Did you use FXRiuby? Anyway, I knew it was a long shot, but it would be
great if they decided to pick this up.
Curt
Martin DeMello
> synaptic), no method of 'making packages available' is going to appeal
> to the general populous (sp?) until then... anyway...
'populace'
martin
Marcel Molina Jr.
> Seattle.rb will be hosting a RubyGems cleanup and enhancement codefest!
Glad to see this happen.
> We would like to solicit your ideas on what you want to see cleaned up
> or enhanced in RubyGems.
*gem query*
will list all gems matching a particular criteria. The
domain may be local, remote or both.
$ gem query -R -n ^m
*gem search*
will list all gems whose name "contains" the given
(case-insensitive) string. If no string is provided, all gems will
be listed.
$ gem search -r log
So one supports regex matches and the other doesn't? One is meant only for
remote queries and the other is indifferent?
There seems to be some overlap here. Perhaps these could be combined into one
command. Perhaps the documentation could be clarified to indicate more
expressly how they *do* differ.
marcel
--
Marcel Molina Jr. <mar...@vernix.org>
Richard Lyman
<snip>
> > > This is probably not feasible, but I'll throw it out there anyway -- I'd
> > > like to see a GUI front-end to RubyGems... a RubyGems browser
> > of sorts.
<snip>
> > I have no idea where my little mockup went, but it only took an hour
> > or so to do, so if someone wanted to, it wouldn't take them long to do
> > their own over again.
>
> Did you use FXRiuby? Anyway, I knew it was a long shot, but it would be
> great if they decided to pick this up.
>
> Curt
>
Yeah - FXRuby. If I wasn't so swamped with school stuff I'd be more
than happy to make a little mockup again... it wasn't that hard... an
FXTreeList on the left side, with some textfields and stuff on the
right for packet specific info...
Like I said though - it was a pretty poor mockup. I really hoped they
would take it to a much higher level (which is probably why I've been
content waiting...).
Maybe I shouldn't wait any more... it would be fun... grr... I _have_
to concentrate on school... This couldn't wait until the end of April
could it? I'd have ~20 a week free time then...
-Rich
Vincent Foley
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.
3) Already mentionned by Gabriele, a cute progress bar (using
progressbar available in RubyGems)
Vincent.
Curt Hibbs
Well, it sure seems unlikely that anyone else is going to do it befoe then,
so I'd say go for it!
Curt
George Moschovitis
2. better support for using just 'require' instead of require_gem
-g.
Ben Giddings
> 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? Choose
some of the main features of RPA that are missing from RubyGems and find
a way of integrating them?
The ones that most interest me are:
== A way of differentiating "stable" and "unstable" packages ==
I don't think this should be a property of the gem, but maybe a
meta-property of some kind. The way Debian, Gentoo and the various BSDs
do things is an example. Someone determines which packages are stable
and which are not, and the user can choose to install the stable version
or the unstable one.
A given package with a given version number may get tested and be
determined to be stable, and be designated "stable". On the other hand,
it may be determined that it is unstable, and so a particular version
might never be made "stable".
== A way of interfacing with various other package managers ==
This may be pie-in-the-sky thinking, but wouldn't it be great if there
were no distinction between installing something via rubygems and
installing it via a package manager? In other words, a debian user
could choose to "gem install foolib" or "apt-get install foolib" and
both would do the same thing? A gentoo user could "gem install foolib"
then later decide he/she doesn't need it and "emerge -C foolib". A
windows user could remove gems using "add/remove programs"?
I think this would be so amazing, but I have no idea how difficult it
would be. If it could work though, I would absolutely love it.
(as an aside, what is the current RubyGems method of removing a gem?)
Ben
Jim Weirich
Ben Giddings said:
> The ones that most interest me are:
>
> == A way of differentiating "stable" and "unstable" packages ==
>
> I don't think this should be a property of the gem, but maybe a
> meta-property of some kind. The way Debian, Gentoo and the various BSDs
> do things is an example. Someone determines which packages are stable
> and which are not, and the user can choose to install the stable version
> or the unstable one.
Part of this can be resolved by the ability to list different Gem sources.
This source (identified by URL) contains stable packages and that source
(a different URL) containts unstable packages. Gems can manage different
sources today, although the interface is primitive. The gems team is
thinking about how to make this more flexible (e.g. get gems from this
source, unless its not available, then get them from that source). This is
certainly something that the Seattle team could work on if they decided
to.
Beyond that, you need a team of people who are willing to test gems,
catogorized them, and then migrate them from unstable to stable.
> (as an aside, what is the current RubyGems method of removing a gem?)
gem uninstall GEMNAME
(http://docs.rubygems.org/read/chapter/10#page38)
--
-- 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)
vruz
> some of the main features of RPA that are missing from RubyGems and find
> a way of integrating them?
Please make a list of features of RubyGems not present in RPA or the
rpa-base client, do the inverse operation and take note.
Now have a look at the codebase of both projects.
Now you understand why not.
Ben Giddings
> Part of this can be resolved by the ability to list different Gem sources.
> This source (identified by URL) contains stable packages and that source
> (a different URL) containts unstable packages. Gems can manage different
> sources today, although the interface is primitive. The gems team is
> thinking about how to make this more flexible (e.g. get gems from this
> source, unless its not available, then get them from that source). This is
> certainly something that the Seattle team could work on if they decided
> to.
Right, but I think you also need some "slots" on the user side. If they
want to keep up to date with the most current stable and unstable gem,
at the same time there should be a way to update them. It seems to me
that if you just have URLs once you've downloaded the gem from the
stable server, your system won't have any memory that that foolib-0.39
is the stable version of foolib.
> Beyond that, you need a team of people who are willing to test gems,
> catogorized them, and then migrate them from unstable to stable.
Right. I don't think that's too difficult though. If we don't have
people who can do this full-time, we could probably also come up with
some kind of a rating system where people can rate the libraries they
use. Libraries passing a certain threshold can be considered 'stable'.
>>(as an aside, what is the current RubyGems method of removing a gem?)
>
> gem uninstall GEMNAME
Ok, I see that option when I say 'gem help commands'. I guess I
expected to see it with 'gem help' or 'gem -h'. My bad.
Ben
David Heinemeier Hansson
> sources.
> This source (identified by URL) contains stable packages and that
> source
> (a different URL) containts unstable packages. Gems can manage
> different
> sources today, although the interface is primitive. The gems team is
> thinking about how to make this more flexible (e.g. get gems from this
> source, unless its not available, then get them from that source).
The Rails team already uses this with much success. Beta gems are
available from http://gems.rubyonrails.com has the edge, the public
repository has the stable. If you have a site to spare, this is already
a much easier approach since you can push as many unstable gems, and as
often as you like, without cluttering a main repository.
--
David Heinemeier Hansson,
http://www.basecamphq.com/ -- Web-based Project Management
http://www.rubyonrails.org/ -- Web-application framework for Ruby
http://www.loudthinking.com/ -- Broadcasting Brain
James Edward Gray II
> Please make a list of features of RubyGems not present in RPA or the
> rpa-base client, do the inverse operation and take note.
>
> Now have a look at the codebase of both projects.
>
> Now you understand why not.
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.)
James Edward Gray II
James Edward Gray II
> Part of this can be resolved by the ability to list different Gem
> sources.
> This source (identified by URL) contains stable packages and that
> source
> (a different URL) containts unstable packages. Gems can manage
> different
> sources today, although the interface is primitive. The gems team is
> thinking about how to make this more flexible (e.g. get gems from this
> source, unless its not available, then get them from that source).
> This is
> certainly something that the Seattle team could work on if they decided
> to.
While I'm on a roll with questions that could get me in trouble (again,
I mean no offense): Was the RubyGems team aware of this Codefest
project before it was accepted? Will any RubyGems members be at the
actual event?
Just curious. Thanks.
James Edward Gray II
vruz
of course not
> 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.)
yes it's still alive, though Mauricio and others have had holidays and
daytime work, we'll be in full steam again soon.
discussions, coordination and all that's rpa-related happens in #RPA
on irc.freenode.net
cheers,
vruz
Eric Hodel
On 14 Mar 2005, at 16:14, James Edward Gray II wrote:
> While I'm on a roll with questions that could get me in trouble
> (again, I mean no offense): Was the RubyGems team aware of this
> Codefest project before it was accepted?
Yes
> Will any RubyGems members be at the actual event?
They're more than welcome, but I can't speak for their plans.
Jim Weirich
> On 14 Mar 2005, at 16:14, James Edward Gray II wrote:
> > While I'm on a roll with questions that could get me in trouble
> > (again, I mean no offense): Was the RubyGems team aware of this
> > Codefest project before it was accepted?
>
> Yes
Yes, and we whole-heartingly approve!
> > Will any RubyGems members be at the actual event?
>
> They're more than welcome, but I can't speak for their plans.
Heh, I doubt I will be able to be there. But depending on when the event is,
I plan on making myself available online as much as possible.
Ryan Davis
On Mar 14, 2005, at 4:50 PM, Eric Hodel wrote:
>> Will any RubyGems members be at the actual event?
>
> They're more than welcome, but I can't speak for their plans.
Chad has hinted that he may be able to show... as for actual
specifics... we don't even have a date yet. We will gladly take his
schedule into consideration when coming up with tentative dates.
Mauricio Fernández
> 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.
As for (2), it is hard to tell which are exactly RubyGems' goals because
AFAIK there is no public manifesto comparable to
http://rpa-base.rubyforge.org/wiki/wiki.cgi?RpaManifesto
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.
--
Hassle-free packages for Ruby?
RPA is available from http://www.rubyarchive.org/
"Peña, Botp"
//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?
//As for (2), it is hard to tell which are exactly RubyGems'
//goals because AFAIK there is no public manifesto comparable to
//http://rpa-base.rubyforge.org/wiki/wiki.cgi?RpaManifesto
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...
kind regards -botp
vruz
> 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 packaging using rpa-base:
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...
Now I wholeheartedly agree.
cheers,
vruz
Austin Ziegler
<batsm...@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.
> As for (2), it is hard to tell which are exactly RubyGems' goals
> because AFAIK there is no public manifesto comparable to
> http://rpa-base.rubyforge.org/wiki/wiki.cgi?RpaManifesto
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.
-austin
--
Austin Ziegler * halos...@gmail.com
* Alternate: aus...@halostatue.ca
Ryan Davis
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
--
ryand...@zenspider.com - Seattle.rb -
http://www.zenspider.com/seattle.rb
http://blog.zenspider.com/ - http://rubyforge.org/projects/ruby2c
vruz
> 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
Mauricio Fernández
> Mauricio Fernández [mailto:batsm...@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.
> //As for (2), it is hard to tell which are exactly RubyGems'
> //goals because AFAIK there is no public manifesto comparable to
> //http://rpa-base.rubyforge.org/wiki/wiki.cgi?RpaManifesto
>
> 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.
Mauricio Fernández
[I write this reluctantly, such a déją vu]
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.
> > As for (2), it is hard to tell which are exactly RubyGems' goals
> > because AFAIK there is no public manifesto comparable to
> > http://rpa-base.rubyforge.org/wiki/wiki.cgi?RpaManifesto
>
> 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.
Jim Weirich
Vincent Foley said:
> On top of my head, I can think of a few things:
>
> 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)
gem cleanup (http://docs.rubygems.org/read/chapter/10#page77)
> 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).
Ben Giddings
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?
Ben
Christian Neukirchen
> //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...
>
> kind regards -botp
--
Christian Neukirchen <chneuk...@gmail.com> http://chneukirchen.org
Chad Fowler
<batsm...@yahoo.com> wrote:
>
> [I write this reluctantly, such a déjà vu]
>
With the same reluctance....
>
> 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.
Let's see if we can let this thread die.
--
Chad Fowler
http://chadfowler.com
http://rubycentral.org
http://rubygarden.org
http://rubygems.rubyforge.org (over 100,000 gems served!)
Ryan Davis
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.
vruz
> thread. We were mining for data and you guys introduced pure noise.
Is STFU an acronym for yet another packaging system ?
Richard Lyman
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.
-Rich
Richard Lyman
<martin...@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...
>
> 'populace'
>
> martin
>
>
Thanks! I was too lazy to 'm-w.com' it.
-Rich
Lyle Johnson
> 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.
Berger, Daniel
> From: Lyle Johnson [mailto:lyle.j...@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?
Just curious.
Dan
Douglas Livingstone
<Daniel...@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
:(
Douglas
Ben Giddings
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.
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?
http://www.dot.state.ia.us/natmodel/images/hammer.gif
Ben
P.S. if you've seen this message before, sorry. I sent it out this
morning but it didn't seem to arrive on the list.
Richard Lyman
That makes more sense. Thanks!
-Rich
Eric Hodel
> 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.
Douglas Livingstone
<bg-ru...@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.
The methods remind me of the "Worse Is Better" concept:
http://www.dreamsongs.com/WorseIsBetter.html
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.
The methods are just different..
Douglas
Richard Lyman
That makes perfect sense then. Thanks for the explanation and good
luck with the enhancements!
-Rich
gsin...@gmail.com
a website dedicated to Ruby packages (like an improved RAA; I know
that's been discussed recently). Allow user reviews, tie it in with
Rubyforge and RAA, allow categorisation as stable or unstable, etc.
Then people can browse the information as they please, and the 'gem'
command-line app can take advantage of the information as well (through
a web service or DRb or whatever).
It's crucial to keep the data separate from the metadata, IMO.
Cheers,
Gavin
Yukihiro Matsumoto
In message "Re: RubyGems, RPA and best tool for the job"
on Wed, 16 Mar 2005 03:24:28 +0900, Chad Fowler <chadf...@gmail.com> writes:
|> I'd happy to merge the packaging system (with
|> which both teams can agree) in the standard Ruby.
|
|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.
I just don't want to discourage one side by merging another. If RPA
camp say "OK, we go our way, nevertheless Gems merged in the
distribution", that's fine for me. Did they?
matz.
Martin DeMello
> On Tue, 15 Mar 2005 22:55:42 +0900, Martin DeMello
> <martin...@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...
> >
> > 'populace'
>
'populous' is a word in its own right, so m-w.com wouldn't have been too
helpful :)
martin