[Rubygems-developers] Gem-Spec Meta Information

Mehr, Assaph (Assaph) assaph at avaya.com
Mon Jul 26 19:30:39 EDT 2004

Curt Hibbs wrote:
> This is a fantastic idea, and is much-needed to enable the mass
> of ruby applications. Also, the 1.8.2 Ruby Installer for Windows is
going to
> include RubyGems and a GUI interface to RubyGems, but Ruby 1.8.2
itself will
> not include RubyGems.

Glad to hear you like it.
What is the GUI interface? Do you have a preview of the source code?

> I think that a set of platform-specific installers for ruby
> could be a breakthrough that makes it viable to create and ship ruby
> -- but only if the target audience for these ruby applications can
> people who are *not* developers (like my grandma).

That's what the NSIS version is for: an standard windows installer.

> I think that for a Ruby application to be viable for mass
distribution, it
> must contain everything it needs to run: the application, the proper
> of ruby, all needed libraries. This is what the windows version of
FreeRIDE does.
> Its really the only way to guarantee a known running environment for
> application. If applications are installed as part of a shared Ruby
> it may or may not work. There is just no way to know. If it doesn't
work, its
> the application that gets blamed, and it may be nearly impossible for
> developer to troubleshoot the problem. This issue disappears
completely when
> the application runs in its own private ruby environment.
> I would suggest creating an app-install-builder that gathers all of
> needed files (app files, ruby runtime files, library files, etc.), and
> builds a custom directory tree containing all of these files that *is*
> runnable application (look at an installed version FreeRIDE to see how
> does it). Then have the app-install-builder generate an
> NSIS script for creating the actual installer.
> The developer can then test his app directly from this newly created
> directory tree. When he is satisfied that everything works, he can run
> to create the actual installer.

I have some objections to this way of doing things. I have seen to many
java apps
distribute the full JRE as part of the app and this way lies madness. I
agree that
It is easier for the developer to control everything via a dedicated
runtime, but that doesn't mean it's also better for society at large.
Issues I see:

1. Ruby-Gems will also pull all required (and versioned) gems.
2. Until a required extension is available as a gem, there is still the
   to generate an NSIS installer and bundle it (Although that is
3. When you distribute this way you tend to branch off from the standard

   runtime releases. You have to maintain your releases as well.

This may make sense to very big apps, but for my purposes keeping a
tighter link
with the ruby runtime is OK.

> I really think that this would be *way* more useful than extending
> applications support.

It is also *way* more work for me :). I'm in favour of picking the lower
fruit first: I am implementing a generic installer-builder that has
platform specific generators: Win32, NSIS, Linux (if someone helps me)
These installers will generate a script that could be run on top of an
Gem. You can always take the output of a generated NSIS script and
modify it
Before building it to include the runtime of your choice.


More information about the Rubygems-developers mailing list