Running applications installed from gems

I suppose rubygems is most often used for packaging libraries, but it
can also be used to package applications. I think it would be
convenient if something like this were supported.

gem run minesweeper

Is this being considered? Are there reasons why this would be a bad
idea?

On Jun 14, 2006, at 5:13 PM, Mark V. wrote:

I suppose rubygems is most often used for packaging libraries, but it
can also be used to package applications. I think it would be
convenient if something like this were supported.

gem run minesweeper

Is this being considered? Are there reasons why this would be a bad
idea?

What’s wrong with just:

minesweeper


Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

On 6/14/06, Mark V. [email protected] wrote:

I suppose rubygems is most often used for packaging libraries, but it
can also be used to package applications. I think it would be
convenient if something like this were supported.

gem run minesweeper

Is this being considered? Are there reasons why this would be a bad idea?

Ruwiki is packaged as a gem. It includes multiple “binary” programs.
Just as #autorequire is a bad idea; #autorun (what would be necessary
to support your idea) would be a bad idea.

-austin

On Thu, Jun 15, 2006 at 12:13:42PM +0900, Austin Z. wrote:

Just as #autorequire is a bad idea; #autorun (what would be necessary
to support your idea) would be a bad idea.

It’s not #autorun but #default_executable, and it is already in
RubyGems.

default_executable
Type: String; Optional; default = (see below)
Description Of all the application files in the package, the default
executable is the one that can be run directly through the gem.
Usage
spec.executables = [‘bin/foo’, ‘bin/bar’]
spec.default_executable = ‘bin/bar’

Notes
If you only specify one application file in executables, that file
becomes
the default executable. Therefore, you only need to specify this value
if
you have more than one application file.
The notion of running applications directly through a gem is not well
supported at the moment. The idea is that you can download a gem, say
monopoly.gem (the board game), and run gem monopoly.gem, which would
run the
monopoly application. This is not an in-demand feature.

It is defacto deprecated and should be removed altogether.

On 6/14/06, Eric H. [email protected] wrote:

What’s wrong with just:

minesweeper

Would minesweeper be a script in the bin directory of the gem?
Can “gem install” add that directory to your PATH?
How would a potential user know what to do in order to run it?

What I’m really after is a simple way for a non-programmer to install
and run a Ruby application that is packaged as a gem.

On 6/15/06, Mark V. [email protected] wrote:

What I’m really after is a simple way for a non-programmer to install
and run a Ruby application that is packaged as a gem.

It’s already done.

Seriously. Try it with Ruwiki or Text::Hyphen. Or PDF::Writer. In
PDF::Writer, a stub for the executable “techbook” is installed
appropriately. It will run the latest version of the software by
default, but you can select a specific version, too.

-austin

On 6/15/06, Austin Z. [email protected] wrote:

On 6/15/06, Mark V. [email protected] wrote:

What I’m really after is a simple way for a non-programmer to install
and run a Ruby application that is packaged as a gem.

It’s already done.

Seriously. Try it with Ruwiki or Text::Hyphen. Or PDF::Writer. In
PDF::Writer, a stub for the executable “techbook” is installed
appropriately. It will run the latest version of the software by
default, but you can select a specific version, too.

Sorry to be dense about this, but how does the user run the
application?

I think what you’re suggesting is that the user

  1. runs “gem install app-name”
  2. navigates to the bin directory of the gem
  3. runs a script found there

Is this what you’re suggesting?

On 6/15/06, Mark V. [email protected] wrote:

Sorry to be dense about this, but how does the user run the application?

I think what you’re suggesting is that the user

  1. runs “gem install app-name”
  2. navigates to the bin directory of the gem
  3. runs a script found there

No.

% gem install ruwiki
% ruwiki_servlet

Or:

% gem install pdf-writer
% techbook

Or:

% gem install text-hyphen
% hyphenate example

-austin

On 6/15/06, Austin Z. [email protected] wrote:

default, but you can select a specific version, too.
% ruwiki_servlet

Or:

% gem install pdf-writer
% techbook

Cool! So I think the last think I need to know is what causes the
“techbook” command to be available. It doesn’t seem that “gem install
pdf-writer” modified my PATH environment variable. I’m running under
Windows and I’m not in the bin directory of the gem when I run
“techbook”. Also, did you do something special in your .gemspec file
to get this to work?

On 6/15/06, Austin Z. [email protected] wrote:

No.

[snip]

% gem install pdf-writer
% techbook

[snip]

What Austin is implying is that after you run the gem command (usually
as root, from any directory), the, say, techbook executable will then
be in your bin directory (for me it’s /opt/ruby-1.8.4/bin). As long as
that bin directory is in a user’s $PATH, that user can then run the
techbook program from any directory just by typing “techbook” at the
prompt.

It’s interesting to note that there’s two versions of a “techbook”
file on my system:

$ ls -l
/opt/ruby-1.8.4/lib/ruby/gems/1.8/gems/pdf-writer-1.1.3/bin/techbook
/opt/ruby-1.8.4/bin/techbook
-rwxr-xr-x 1 root root 419 2006-06-15 12:39 /opt/ruby-1.8.4/bin/techbook
-rw-r–r-- 1 root root 594 2006-06-15 12:39
/opt/ruby-1.8.4/lib/ruby/gems/1.8/gems/pdf-writer-1.1.3/bin/techbook

I don’t know enough about gems to say:

  • what the /opt/ruby-1.8.4/bin/techbook executable was generated from,
    or
  • what the gems/pdf-writer-1.1.3/bin/techbook file is for.

I don’t see anything in the RubyGems faq or the RubyGems manual about
generating executables in gems. The GemSpec reference briefly mentions
executables and the bindir, but I don’t see anything about why you
might have two, or one generated from another…

—John

On 6/15/06, Mark V. [email protected] wrote:

Cool! So I think the last think I need to know is what causes the
“techbook” command to be available. It doesn’t seem that “gem install
pdf-writer” modified my PATH environment variable. I’m running under
Windows and I’m not in the bin directory of the gem when I run
“techbook”. Also, did you do something special in your .gemspec file
to get this to work?

Sy my first reply about “a stub for …” being created. I elaborate in
my reply to John G… Yes, something has to be done – the
executable has to be named. It seems I forgot to do so in
Text::Hyphen, which means that the third example that I gave … won’t
work. :wink:

-austin

On 6/15/06, John G. [email protected] wrote:

techbook program from any directory just by typing “techbook” at the

I don’t know enough about gems to say:

  • what the /opt/ruby-1.8.4/bin/techbook executable was generated from, or
  • what the gems/pdf-writer-1.1.3/bin/techbook file is for.

The one in /opt/ruby-1.8.4/bin is the RubyGems stub. That’s in your
$PATH, because that’s where your ruby executable is. The one in
…gems/pdf-writer-1.1.3/bin/techbook is my actual executable. The
RubyGems stub will activate the PDF::Writer 1.1.3 gem (actually, the
latest unless you select a specific version) and then “run” the one in
the gems/… path, which is not in your $PATH.

-austin

Mark V. wrote:

default, but you can select a specific version, too.

Sorry to be dense about this, but how does the user run the application?

I think what you’re suggesting is that the user

  1. runs “gem install app-name”
  2. navigates to the bin directory of the gem
  3. runs a script found there

Is this what you’re suggesting?

Hi Mark,

When you install a gem, Gems will place executables to the appropriate
location to be called from the command line. You need not do anything
special. Are you using Windows by chance? While I’m sure it basically
works the same way there, I’m just not sure how it handles it. In Linux
executables will be created in /usr/bin that load up the gem’s bin/
file.

HTH,
T.

On 6/15/06, Austin Z. [email protected] wrote:

[snip]
The one in /opt/ruby-1.8.4/bin is the RubyGems stub. That’s in your
$PATH, because that’s where your ruby executable is. The one in
…gems/pdf-writer-1.1.3/bin/techbook is my actual executable. The
RubyGems stub will activate the PDF::Writer 1.1.3 gem (actually, the
latest unless you select a specific version) and then “run” the one in
the gems/… path, which is not in your $PATH.

Ah… I see. Thanks Austin. I’d forgotten that RubyGems allows
multiple versions of the same gem to be installed. But since the
exectuable stub is in a common directory, there’s gotta be some way
for it to decide which version of the given gem to actually run.

So, I guess the convention then – for when you want to supply an
executable with a gem – is to tell the GemSpec you want a stub which
calls “load ‘foo’”. When that foo file is loaded, your app should run.
In the case of pdf-writer, both the stub and the module you load to
actually run the program happen to have the same name.

Further, I see that both
…/lib/ruby/gems/1.8/gems/pdf-writer-1.1.3/bin and
…/lib/ruby/gems/1.8/gems/pdf-writer-1.1.3/lib directories are in $:
when that “load ‘techbook’” call is made from the stub.

Chapter 7 of the RubyGems user’s guide
(http://docs.rubygems.org/read/chapter/5) doesn’t have much, but
refers the reader to the DeveloperGuide, but I don’t see a link to
that on the main RubyGems page.

I hopped over to my …/lib/ruby/site_ruby/1.8 directory, ran rdoc,
and had a look in the resulting lovely html, but didn’t see a dev
guide in there either. Where can I find this developer’s guide?

On 6/15/06, John G. [email protected] wrote:

Ah… I see. Thanks Austin. I’d forgotten that RubyGems allows
multiple versions of the same gem to be installed. But since the
exectuable stub is in a common directory, there’s gotta be some way
for it to decide which version of the given gem to actually run.

I think that it’s:

techbook 1.1.3

-austin

On 6/15/06, I:

[snip]

Where can I find this developer’s guide?

Whoops. Found the DeveloperGuide page on the RubyGems wiki.

On 6/15/06, Austin Z. [email protected] wrote:

On 6/15/06, John G. [email protected] wrote:

Ah… I see. Thanks Austin. I’d forgotten that RubyGems allows
multiple versions of the same gem to be installed. But since the
exectuable stub is in a common directory, there’s gotta be some way
for it to decide which version of the given gem to actually run.

I think that it’s:

techbook 1.1.3

Right. Sorry – I was thinking out loud, describing how the system
must work since it allows multiple versions of the same gem.

Austin Z. wrote:

On 6/15/06, John G. [email protected] wrote:

Ah… I see. Thanks Austin. I’d forgotten that RubyGems allows
multiple versions of the same gem to be installed. But since the
exectuable stub is in a common directory, there’s gotta be some way
for it to decide which version of the given gem to actually run.

I think that it’s:

techbook 1.1.3

That’s correct. For example:

$ gem list -l rake

*** LOCAL GEMS ***

rake (0.7.1, 0.7.0)
Ruby based make-like utility.
$ rake --version
rake, version 0.7.1
$ rake 0.7.0 --version
rake, version 0.7.0

BTW, Rake was the first software available as a gem, and it has always
been an application. Application support has been there from the start.

– Jim W.