[Rubyinstaller-devel] Working with multiple Ruby versions

Luis Lavena luislavena at gmail.com
Sat Aug 23 03:25:51 EDT 2008

On Fri, Aug 15, 2008 at 8:01 PM, Lars Christensen <larsch at belunktum.dk> wrote:
> Hi,

Hey Lars!

Sorry took me so long get back to you, kind of hectic lately.

> I'd like the option to work with multiple ruby versions in the same
> rubyinstaller directory, primarily to speed up 'rake' operations and to
> avoid multiple downloads, extracts, etc. Also, the current 'cp' operation on
> the ruby sources code when checking out from SVN is very slow.

I was thinking that we need to establish a "label" for those different
version, and also get rid of the checkout and copy procedure, whcih is
suboptimal like you said.

> My suggestion is to put the source/build/install targets into separate
> directories, depending on the origin and version of the Ruby source.
> For example, when pulling from SVN:
> sandbox/ruby_source/svn/tags/v1_8_6_114
> sandbox/ruby_build/svn/tags/v1_8_6_114
> sandbox/ruby_mingw/svn/tags/v1_8_6_114
> Or a branch:
> sandbox/ruby_source/svn/branches/ruby_1_8
> Or from the tarball:
> sandbox/ruby_source/ruby-1.8.6-p114

Hmn, I was thinking something more in the lines of what multiruby
does, but with a twist:


version can be tag, branch, tarball signatures, like 1_8 (for branch)
or 1_8_6_114 for tag and 1.8.6-p114 for tarball.

In any case, I'm considering labeling those version as stable, current
and candidate for ruby18 and ruby19 ;-)

> I've pushed some changes to
> http://github.com/larsch/rubyinstaller/commits/nocopycheckout2/ which
> implements the above. You can set the SVN URL in config/ruby_installer.rb,
> and it will then decide a path on it's own, from the contents of the URL.
> This can still be overridden by setting the options, e.g. :checkout_target,
> but by default they are left out and generated by the script.

Didn't had time to take a look, gut I think that
config/ruby_installer.rb purpose hit another wall issue. When I first
designed it was not ready to handle all this different context, and
turned to be smaller for what we are trying to do.

I've been playing with a rewrite of the task, in the lines of the
openssl one, but with another twist.

a YAML file that specify a single download, a checkout or series of
files (packages) for different versions like stable, current and

Then, a parametrized rake task for ruby18 which always depend on gcc,
zlib, openssl versions. Unless you specify, it always build stable.

If you want a different version, just say: rake ruby18[candidate] and
you can also tweak openssl[current] instead of the stable default.

ruby18 is not depending on a specific openssl task, but on also a
parametrized one. Maybe is stupid, I know :-P

Thanks Lars for presenting those scenarios, will be cool if we have a
formal "meeting" to discuss next steps (Gordon, you and me) --- and
anyone that want to join us! :-D

Luis Lavena
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

More information about the Rubyinstaller-devel mailing list