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

Chad Fowler chad at chadfowler.com
Thu Mar 18 07:11:51 EST 2004

On Mar 17, 2004, at 11:09 PM, Gavin Sinclair wrote:

> 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/   :)

I need a vacation.  I was falling asleep as I wrote this :)

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

Right.  Sorry, I forgot to explain that.

>> 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.

Matz wanted it to be easy for people to download a file and "run" it.  
He was envisioning something akin to "java -jar blah.jar", if you're at 
all familiar with Java.  The problem with us taking the same approach 
Java did (actually leave the code in the gem file and loading it from 
there) is that we wouldn't be able to easily--at all--do that with 
binary extensions.

>> 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.

I guess I didn't mean that having a personal gem directory was 
appealing so much as the ability to automatically run an application 
without installing it.  Or, even after having installed an application, 
gem --run would give you a symbolic way to reference and run it.  It's 
kind of reminiscent of MacOSX's Blah.app structure.  In the Finder, 
"TextEdit" looks like a simple single-file application that can be run. 
  If you go into the Applications directory with a shell, you'll find 
that "TextEdit" is really a directory called "TextEdit.app", with 
subdirectories containing executables, help files, and metadata.  You 
can even find (and modify, I think) the piece of metadata that 
specifies which executable to run when a user runs the symbolic 
"TextEdit" application.

So, this is what I think is appealing.  Not the implementation, but the 
idea of being able to easily "run" an otherwise jumbled and loose 
collection of files and have it mean something.

> 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.

We have a --dir switch right now, along with the $GEM_PATH environment 
variable.  I'm not sure whether --user and --system are needed in that 
case.  It might be better to let people manage what that would mean to 
them separately?

> 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?

We might want to forget about my potentially very flawed 
one-man-email-brainstorming session.  Is it "running" the gem that 
isn't appealing to you or the implementation I suggested?  It sounds 
like it's my suggested implementation that you don't like.  I think the 
simple solution is to decide that you have to install a gem before you 
can "run" it.  I think it's a decent compromise.  Perhaps, then the 

gem --run mygem-0.1.1.gem

...would first ask you if you would like to invoke the installer.  If 
you say "no", you can't run the gem.  If you say "yes", it installs and 
then runs it.

>> 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.

Seems reasonable, though the "/" makes me think we're pointing to a 
file, which I don't think we would be in this case.  It would only be 
symbolic, unless we were to specify a "binpath" in the gem or 
something.  In that case, you would have a default app "gem --run 
rubygems" which would be run if you specify nothing but the gem name 
and then any gemname/otherprogram calls would get translated into 
#{gemdir}/#{gembindir}/otherprogramname.  Is this what you were 

> 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?
> :)

hehe.  I'm starting to think we should somehow segment it.

> 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.

Yes.  Though, I'd like to see us make some big ones.

> 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.

Have you played with Rublog much?  It might be conceptually very 
similar (in its guts) to what you want to do.  At RubyConf, I wrote a 
Rublog convertor that syndicated a gem repository.

Mauricio Fernandez ("batsman" on irc) has a tool called RDocSite which 
may also be related.

More information about the Rubygems-developers mailing list