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

Mehr, Assaph (Assaph) assaph at avaya.com
Thu Sep 23 21:52:00 EDT 2004


Curt wrote:
>> Maybe it would be better if your app-gem-installer was run as
>> the top-level script and just used rubygems with in it. That 
>> way you are in control and can run any pre or post installation
>> steps you like.

That's a nice idea, though probably encroaching on RPA territory :-)
If I go that way I'll probably prefer to use just the NSIS generated
installer, but this could work on other platforms I guess.
Although as Mauricio pointed out, this is something best left for
professionals: There are many issues I am unaware of.

Austin wrote:
> If coupled with the "gem run <gemname> <execfile>" concept, esp.
> If this functionality is made available programmatically, then the
> app-gem-installer could do this as a functionality option:
>   if %x{gem has <gemname> <execfile>} then %x{gem run <gemname>
<execfile>}

Again, kinda misses the point - there is the question as to who does
what: who is responsible for a fully integrated installation, the user
or the installer?
Maybe I'll start at the beginning and describe my way of thinking.
Critiques most welcome.

I am writing an application that I need to distribute to others in my
department.
This is GUI app (wxRuby) and the environment is MS Windows. Current
distribution process is:
* Install Ruby (1-click)
* Install wxRuby (1-click)
* Install Log4r (unzip, double-click install.rb)
* Unzip my app.zip file and either create shortcuts or run from cmd.
When I release an update, users just need to unzip the app.zip file in
the same place.

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. 

NSIS solves just my problem, for a single app only.
The second method has more advantages:
* I get an instant 'update' facility by providing a start-menu link to
'gem i myapp' (cause 'gem update' updates all installed packages).
* Updates to log4r (and later wxRuby) could also be easily distributed.
Also, if I introduce a new dependency - no problem, it'll be picked up
by gems.
* I may end up with something valuable to the community as a whole.

Now this is probably where my logic breaks. My idea about how to achieve
that was (is):

* Have a field in the gemspec for meta-data attributes. (I had a sample
implementation before the spec format changed; I hope to redo it soon).
This is simply a hash, and any data can be placed in it.

* App-gems creators can put system-integration bindings in that hash.
Examples are start-menu shortcuts, file-type associations etc. The keys
are defined by the app-gem-installer.

* The app-gem-installer can work in two essentially different modes. It
will query a gemspec for the meta-data and then either:
  - (User-side) do the integration itself on the end-user machine. 
    There should be backends to handle most OSs.
  - (Dev-side) produce an independent install scrip (NSIS, ruby or
other). 
    This script could then be distributed/act upon by the dev team.

Ideally, for a seamless integration into rubygems and a better install
process, I hoped developers could still simply release the gem (with the
meta-data) as usual. When a user installs the application through
rubygems, rubygems will ask the user if he wants this integration, and
then do it.

Alternately, the devloper could release an independent installer, and
the app-gem-installer will be a tool to do it easily. Yes, since one of
the output methods can be a ruby script I can create something that will
supercede rubygems. It can call 'gem i app' and then run the
integration. But that means that the developer has to create such an
output script for each target platform and distribute those.

Ideally (to my view) this functionality should be integrated with
ruby-gems (or rpa-base or any other packaging distribution mechanism).
The platform doing the installation will then be able to offer a
*complete* installation for an application, not just bringing the
package and leaving the user to finish the work himself.

Thoughts so far?

Assaph




More information about the Rubygems-developers mailing list