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.
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).
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
···
On Sat, Mar 12, 2005 at 11:27:48AM +0900, Eric Hodel wrote:
--
Marcel Molina Jr. <marcel@vernix.org>
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?)
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)
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).
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
···
On Sat, 12 Mar 2005 14:07:19 +0900, Curt Hibbs <curt@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).
== 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?)
--
-- Jim Weirich jim@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)
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?
Please make a list of features of RubyGems not present in RPA or the
rpa-base client, do the inverse operation and take note.
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 jim@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)
>
> 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.
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.
> 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
···
On Sat, 12 Mar 2005 14:07:19 +0900, Curt Hibbs <curt@hibbs.com> wrote:
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.
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).
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.
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
···
On Mar 14, 2005, at 5:18 PM, vruz wrote:
Please make a list of features of RubyGems not present in RPA or the
rpa-base client, do the inverse operation and take note.
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
···
On Mar 14, 2005, at 4:47 PM, Jim Weirich wrote:
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.
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.