Rubyinstaller devel - Aug 2008 - Working with multiple Ruby versions

Hi,

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.

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

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.

Lars

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:

sandbox/ruby_{version}/source
sandbox/ruby_{tag,branch}/build
sandbox/ruby_{tag,branch}/package

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
candidate.

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
AREA 17
-
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

On Sat, 23 Aug 2008, Luis Lavena wrote:
>> 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.
> sandbox/ruby_{version}/source
> sandbox/ruby_{tag,branch}/build
> sandbox/ruby_{tag,branch}/package
That appears more clean to me. I''ll update my approach.
> 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.
>
> 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.
Yes, it does seem abit awkward. Some parameters can be derived from 
others, such as paths from SVN urls etc. That is not so clean when 
creating OpenStructs.
> 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
> candidate.
>
> 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.
Is the [] syntax something from Rake?
> 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
Sure. What form?


Lars