[Rubygems-developers] Thoughts on handling bin and man files

Gavin Sinclair gsinclair at soyabean.com.au
Thu Mar 18 15:09:26 EST 2004


On Thursday, March 18, 2004, 1:50:19 PM, Chad wrote:


> On Mar 17, 2004, at 9:42 PM, Gavin Sinclair wrote:

>> One open issue with RubyGems is handling applications and not just
>> libraries.  Libraries are "easy" in the RG model because RG mangles
>> Ruby's $LOAD_PATH.  That's not so easy with applications.
>>
>> There are two options as I see it.  [...]

> For what it works, I've been thinking about option 2. I don't think
> symbolic links is an option.

s/it works/it's worth/   :)

Is that because of platform issues?  If so, fair enough.

> I know that Matz (from RubyConf 2001) was very interested in being
> able to distribute a single-file Ruby application. To me, gem --run
> can fill that need, though the files will end up being extracted. As
> long as it's transparent, it shouldn't matter. You could even do:

> gem --run mygem-0.1.1.gem

> ...and it could extract the gem to a personal directory if it's not 
> already installed (either globally or locally) and run transparently.

This wouldn't prevent a "single-file Ruby application" from failing
because a required library was not installed.  I wonder what Matz had
in mind.

> That's kind of appealing.

Novel, but not that appealing to me.  I've never used a "personal"
gems directory, but I guess that's important on a multi-user machine.
What about:

  gem -i ruby-doom --system    # I prefer this as default.
  gem -i ruby-doom --user      # Use $HOME/.gems or something.

Then require_gem should search both places.  Of course, then the
"list" and "search" operations need to take it into account.  So the
following permutations are possible:

  gem --list --user            # Implies --local
  gem --list --system          # Implies --local
  gem --list --local           # Lists user and system packages
  gem --list --remote          # Lists remote packages
  gem --list                   # Lists local and remote packages

(This assumes the interface I wrote about recently.)

Modifying all the operations to know about --user and --system might
be a fair bit of work, but I think it's very worthwhile.

BTW, "running" a gem file as you suggest doesn't appeal to me because
I don't know whether the installation of the gem will be temporary or
permanent.  It sounds temporary (since you're not actually asking gem
to install it), but would you *really* uninstall it after running?


> Of course, we would soon run into the problem that some "applications"
> come with two or more executables that you might run.  Take RubyGems
> for example. :) (gem and gem_server)

My take on that:

  gem --run rubygems               # Default app 'gem'.
  gem --run rubygems/gem           # Make it explicit.
  gem --run rubygems/gem_server    # Run the server.

So what about man pages?  Same thing?

  gem --man rake

I kinda like this as well:

  gem --readme rake

This locates Rake's README (using a RubyGems convention and/or
metadata) and pushes it through $PAGER (or in the case of Windows,
opens it in Notepad or something).

That would hopefully encourage people to create useful README files and
mean there's no need for man pages.  You'd lose some formatting, but
that's too bad.  When an all-powerful gem browser emerges, it could
run RDoc on the README to regain some formatting.

I certainly like the idea of a very powerful 'gem' frontend, don't I?
:)

Cheers,
Gavin

P.S. Nice to see code being written, RubyGems being released, and
ideas being discussed.  Progress by small steps pays off in the end.

P.P.S. My main project at the moment (not that I have time,
unfortunately) is "RDocWeb", which creates pages exactly like
http://ruby-doc.org/stdlib, but in a generalised sense (i.e.
containing whatever packages you want).  When that's done, a program
could easily generate such a page for all of your installed gems.



More information about the Rubygems-developers mailing list