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?
--
R. Mark Volkmann
Object Computing, Inc.
What's wrong with just:
minesweeper
On Jun 14, 2006, at 5:13 PM, Mark Volkmann 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?
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
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 6/14/06, Mark Volkmann <r.mark.volkmann@gmail.com> 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?
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
* austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
* austin@zieglers.ca
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 Thu, Jun 15, 2006 at 12:13:42PM +0900, Austin Ziegler wrote:
On 6/14/06, Mark Volkmann <r.mark.volkmann@gmail.com> 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.
--
Mauricio Fernandez - http://eigenclass.org - singular Ruby
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/14/06, Eric Hodel <drbrain@segment7.net> wrote:
On Jun 14, 2006, at 5:13 PM, Mark Volkmann 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
--
R. Mark Volkmann
Object Computing, Inc.
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, Mark Volkmann <r.mark.volkmann@gmail.com> 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.
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
* austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
* austin@zieglers.ca
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, Austin Ziegler <halostatue@gmail.com> wrote:
On 6/15/06, Mark Volkmann <r.mark.volkmann@gmail.com> 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.
--
R. Mark Volkmann
Object Computing, Inc.
No.
% gem install ruwiki
% ruwiki_servlet
Or:
% gem install pdf-writer
% techbook
Or:
% gem install text-hyphen
% hyphenate example
-austin
On 6/15/06, Mark Volkmann <r.mark.volkmann@gmail.com> wrote:
On 6/15/06, Austin Ziegler <halostatue@gmail.com> wrote:
> On 6/15/06, Mark Volkmann <r.mark.volkmann@gmail.com> 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
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
* austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
* austin@zieglers.ca
Mark Volkmann 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 thereIs 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 Ziegler <halostatue@gmail.com> wrote:
> On 6/15/06, Mark Volkmann <r.mark.volkmann@gmail.com> wrote:
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, Austin Ziegler <halostatue@gmail.com> wrote:
On 6/15/06, Mark Volkmann <r.mark.volkmann@gmail.com> wrote:
> On 6/15/06, Austin Ziegler <halostatue@gmail.com> wrote:
> > On 6/15/06, Mark Volkmann <r.mark.volkmann@gmail.com> wrote:
> > [snip]
> 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 thereNo.
[snip]
% gem install pdf-writer
% techbook[snip]
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 Ziegler <halostatue@gmail.com> wrote:
On 6/15/06, Mark Volkmann <r.mark.volkmann@gmail.com> wrote:
> On 6/15/06, Austin Ziegler <halostatue@gmail.com> wrote:
> > On 6/15/06, Mark Volkmann <r.mark.volkmann@gmail.com> 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 thereNo.
% gem install ruwiki
% ruwiki_servletOr:
% gem install pdf-writer
% techbook
--
R. Mark Volkmann
Object Computing, Inc.
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
On 6/15/06, John Gabriele <jmg3000@gmail.com> wrote:
> [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/techbookI 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.
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
* austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
* austin@zieglers.ca
Sy my first reply about "a stub for ..." being created. I elaborate in
my reply to John Gabriele. 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. 
-austin
On 6/15/06, Mark Volkmann <r.mark.volkmann@gmail.com> 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?
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
* austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
* austin@zieglers.ca
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, Austin Ziegler <halostatue@gmail.com> 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.
I *think* that it's:
techbook _1.1.3_
-austin
On 6/15/06, John Gabriele <jmg3000@gmail.com> 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.
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
* austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
* austin@zieglers.ca
On 6/15/06, I:
[snip]
Where can I find this developer's guide?
Whoops. Found the DeveloperGuide page on the RubyGems wiki.
Right. Sorry -- I was thinking out loud, describing how the system
must work since it allows multiple versions of the same gem.
On 6/15/06, Austin Ziegler <halostatue@gmail.com> wrote:
On 6/15/06, John Gabriele <jmg3000@gmail.com> 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 Ziegler 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 Weirich