[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
distribution
> 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
applications
> could be a breakthrough that makes it viable to create and ship ruby
applications
> -- but only if the target audience for these ruby applications can
include
> 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
version
> 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
the
> application. If applications are installed as part of a shared Ruby
runtime,
> 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
the
> 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
the
> needed files (app files, ruby runtime files, library files, etc.), and
then
> builds a custom directory tree containing all of these files that *is*
the
> runnable application (look at an installed version FreeRIDE to see how
FreeRIDE
> 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
NSIS
> 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
private
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
option
   to generate an NSIS installer and bundle it (Although that is
problematic).
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
RubyGems
> applications support.

It is also *way* more work for me :). I'm in favour of picking the lower
hanging
fruit first: I am implementing a generic installer-builder that has
serveral
platform specific generators: Win32, NSIS, Linux (if someone helps me)
etc.
These installers will generate a script that could be run on top of an
installed
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.

Thoughts?



More information about the Rubygems-developers mailing list