[Rubygems-developers] Application gems (was: Two feature requests)

Mehr, Assaph (Assaph) assaph at avaya.com
Sun Sep 26 19:35:18 EDT 2004

> Nice email, Assaph!.....

Thanks for the kind words :-)

>> Now that's not a nice way to do it. So I thought to myself, let's
>> improve this. The two options I could think of:
>> * Build a dedicated NSIS installer
>> * Do something on top of RubyGems.
> Everything up to here makes RubyGems sound like an obvious choice.  
> It's, of course, the creation of shortcuts, etc. that we don't have 
> available in RubyGems.
> I'll snip out the rest of this message and ask a question:  For 
> Windows, what functionality do you want from a post-install script or 
> whatever implementation we might come up with?  Are you looking for an

> obvious, finite set of functions or are you truly in need of complete 
> freedom to (on the user's OK) do whatever you like in a ruby script?

Post-install scripts are a general solution to the problem, not
necessarily the best. They are not strictly needed for a
system-integration step, as that can be achieved as a separate,
self-contained step.
However, since two gems already need this, and since many more can
benefit from things like checking external dependencies (e.g. checking a
specific utility is available), I thought I'd present this as a general

> I see there being 3 possibilities:
> 1. Offer a full-blown post-(and pre?)-install capability for RubyGems.

I believe this is the best solution. As you state below, If the user
says OK then he probably agrees. I think the best solution is something
along the lines of having 2 gemspec attributes: one for the script name
one for a description. It can the be used as (pesudo-code):

if ask_yes_no "The creator of the gem requests to run #{spec.post_inst}
		   to do: #{spec.post_inst_desc}"
  system spec.post_inst

At which point the user can read the reason for the script and choose
whether to view the named script before deciding.

I don't think there is particular need for a distinction between pre-
and post- install steps. All dependencies etc. can be checked
post-installation and warnings issued to the user if further actions are
The only thing I can think of where it may be beneficial is in compiled
extension, but this whole section probably needs overhaul.

> 2. Use RubyGems to auto-generate platform-specific installers with 
> enhanced capabilities
> 3. Create metadata extensions on a per-platform basis that provide a 
> fixed set of capabilities (that would be included as extensions to 
> RubyGems) for integrating with various platforms.  In Windows, this 
> might mean modifying the PATH, updating the registry, or creating 
> shortcuts.

Not sure I get the distinction between the above two points: isn't 3
just a means of achieving 2? I'd rather keep everything in pure-ruby
(easier to maintain). The actual integration will be delegated to
os/arch specific classes. These classes can be part of the standard Gem
installation. The post-install step would simply be to call them with
the newly installed gem.

The modus operandi of such classes (in an ideal world) should be to
present the user with something like: "This gem can be ingerated with
your system more closely. Proceed? [yes/no/more info]". If the user
chooses 'more info' he will be presented with an (overridable) list of
what's about to change: modifications to PATH, shortcuts,
file-extensions associations etc. If the user chooses 'yes', the
modifications will be done and some uninstall information will be

As a bonus, since we keep all the install information as meta-data in
the gemspec, we can write "plugins" that will not do the integration but
output a complete installer (e.g. NSIS). But this is best left an
ancillary tool to the gem creator to run. Rubygems could integrate any
application gem with the platform where it's run, but the gem creator
will have to maintain such scripts and the distribution of dedicated

> I'm a bit uncomfortable with the pre/post-install free-for-all idea, 
> though if the gem installer asks the user if it's OK I'm not sure
> it makes me uncomfortable. :)  I'm sure we should do _something_ for 
> 0.9.0, but I'm not settled on exactly what yet.
> Assaph, I appreciate what you're doing here immensely.  I'm sure we'll

> come up with the right solution if we keep going down this path.

Hope that clears things a bit more. I'm sure we can get an agreeably
workable solution in time. I can help (a bit) by submitting patches to
some of these small tasks.


More information about the Rubygems-developers mailing list