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

Chad Fowler chad at chadfowler.com
Wed Mar 17 21:50:19 EST 2004


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.  Let's take the case of an
> application "date.rb" that tells you the date.  It's packaged into
> "date.gem" and we want to install it.  Here are the scenarios.
>
> 1. Use symbolic links.
>
> Installing "date.gem" plants the following symbolic link:
>
>   /usr/local/bin/date.rb -> $GEMDIR/date-0.1/bin/date.rb
>
> Uninstalling "date.gem" sweeps /usr/local/bin, looking for symbolic
> links to anything under $GEMDIR/date-0.1/bin and removing them.
>
> Note that in this case, date.rb must still use 'require_gem' to
> resolve any date-related libraries.  This, I suggest, is bad.
>
>
> 2. Mangle $PATH, which requires a 'gem' frontend.
>
> Installing "date.gem" requires no special tricks for bin files.
> However, in order to run it, you must do this:
>
>   gem --run date
>
> This:
>  - looks for a locally-installed gem called 'date'
>  - determines its default executable (another piece of metadata),
>    which is "date.rb"
>  - runs "date.rb"
>    - "date.rb" must transparently be able to find date-related
>      libraries, so 'require_gem "date"' must somehow find its way in
>      there
>
>

For what it works, I've been thinking about option 2.  I don't think 
symbolic links is an option.  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.  
That's kind of appealing.

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)

Chad



More information about the Rubygems-developers mailing list