[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
> include RubyGems and a GUI interface to RubyGems, but Ruby 1.8.2
> 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
> must contain everything it needs to run: the application, the proper
> of ruby, all needed libraries. This is what the windows version of
> 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
> the application that gets blamed, and it may be nearly impossible for
> developer to troubleshoot the problem. This issue disappears
> 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
distribute the full JRE as part of the app and this way lies madness. I
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
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
Before building it to include the runtime of your choice.
More information about the Rubygems-developers