[Rubygems-developers] Modified usage information, and several
chad at chadfowler.com
Wed Mar 17 10:09:13 EST 2004
On Thu, 18 Mar 2004, Gavin Sinclair wrote:
# I noticed the --help information was a bit cluttered and modified the
# source to improve it. The patch is at EOF; the new output is below.
Much better, thanks. The patch has been applied. This was on my personal
TODO list. :)
# 2. I would like to make the following changes, but only suggest them
# at this stage: --search should search *locally*, and
# --remote-search should be provided for what --search does now.
# This would be consistent with --list and --remote-list.
I agree with this. I don't have time to get to it immediately, but what I
would probably do is put a search method on the cache (just cutting and
pasting the search from RemoteInstaller) and delegate there
from the RemoteInstaller's search method. That would make it very easy to
do the local search.
# 3. I made '-r' an alias for '--remote-install'. '-r' may be a poor
# choice, but something is necessary.
I don't see a problem with it, personally.
# 4. Suggestion: interactive mode, making it easier to browse the
# remote repository and install, etc. That's a bit far out for now
# and not a core competency.
I see this as being the job of some kind of gem browser, which could be a
graphical, console, or web app. The web app would probably look something
like an RAA
# 5. Suggestion: 'gem --gen-rdoc GEMNAME' to generate the RDoc for an
# already-installed gem. '--gen-rdoc' exists at the moment, but can
# only be used (AFAIK) when installing a gem.
I agree. I started on this a couple of days ago and didn't get anywhere
# 6. Suggestion: 'gem --browse', which runs a Webrick app and opens a
# web browser allowing you to browse your installed gems (and query
# remote ones, perhaps), including description and generated
Have you looked at gem_server at all? It needs some cleaning, but it's
the beginning of what you're describing.
# 7. Pursuant to (2) above, think about this: we have installing,
# searching, listing, and displaying info. And orthogonally, we have
# local and remote operations. What about this sort of interface
# instead of what we have now?
# gem -i jabber4r
# * looks for local gemfile
# * failing that, looks for remote one if possible
# gem -s doom
# * searches local packages for 'doom' and reports
# * also performs remote search if possible and reports
# * note this implies -s as shortcut for --search
# gem --list F
# * lists local gems beginning with 'F'
# * argument 'F' is optional and case insensitive
# * lists remote gems if possible
# gem --info jabber4r
# * looks locally for package information
# * attempts remote lookup so
# * we get the information even if it's not installed locally
# * we can see if there's a more recent version
# All the above examples describe *default* behaviour. The
# modifiers --local and --remote force them to behave one way or the
# I'm happy to do the work on this (yeah, you've heard that before)
# but obviously the idea needs buy-in. I'm really busy ATM but this
# stuff ain't hard.
I like this idea. Any other opinions?
# Q: is there an easy and quick way to determine whether a computer
# is connected to the internet?
Not that I know of (at least not a clean and portable way). You also have
to take into account that some people are behind firewalls and proxy
servers, so they aren't really directly connected to the internet, but
they have the capabilities that rubygems requires.
# 8. Now that everyone's using Ruby 1.8 (that's assumed for RubyGems
# isn't it?), and therefore RDoc is installed, let's make gem
# installation include RDoc generation by default.
I don't have an opinion either way on this. We are assuming Ruby 1.8. In
fact, the message I sent to ruby-talk that finally spurred RDoc's
inclusion was because we wanted to do RDoc support but didn't want to
depend on anything not included with Ruby.
# 9. When performing a search, display the N closest matches (where
# 0 < N <= 5). This is really easy. I've mentioned this on
# ruby-talk but may as well include it here.
Yea. The fuzzy match snippet from RubyForge wasn't all that reliable, but
it's not a bad idea to work on.
# 10. Suggestion: 'gem --updates' to inform you of available updates to
# packages you already have installed.
# 11. Worth having a man page?
Why not? It's all a matter of priority and amount of effort that we can
all put in.
Thanks for the code and excellent suggestions.
More information about the Rubygems-developers