Rubyinstaller devel - Jun 2009 - Pik and GEM_HOME, GEM_PATH and my environment

Hello Guys,

I wanted to share my lovely experience so far using Pik...

I just love it!

Gordon: thank you for making by batch files (rb18 and rb19) deprecate
so easily :-D

I''ve a few comments so far on this, and my results of trying to hack
GEM_PATH and GEM_HOME in the gem_home branch, please take those with a
grain of salt since I haven''t invested a lot of time on understanding
Pik too much :-D

First, my background:

I don''t install gems inside each ruby installation. Instead, I install
them into a share ".gems" place in my HOME.

But I don''t share gems between 1.8.x and 1.9.x (which is a bummer for
binary gems)

So, what I did is follow what Gem.default_path returns:

C:\Users\Luis\Tools>SET GEM_HOME
C:\Users\Luis\Tools>SET GEM_PATH
GEM_PATH=C:\Users\Luis\.gem\ruby\1.8

C:\Users\Luis\Tools>irb
irb(main):001:0> require ''rubygems''
=> true
irb(main):002:0> Gem.default_path
=> ["C:\\Users\\Luis/.gem/ruby/1.8",
"C:/Users/Luis/Tools/Ruby/ruby-1.8.6-p368-i386-mingw32/lib/ruby/gems/1.8"]
irb(main):003:0>

As you can see, the first option is ".gem/ruby/1.8"

Now, the same for 1.9.x:

C:\Users\Luis>irb
irb(main):001:0> require ''rubygems''
=> false
irb(main):002:0> Gem.default_path
=> ["C:\\Users\\Luis/.gem/ruby/1.9.1",
"C:/Users/Luis/Tools/Ruby/ruby-1.9.1-p129-i386-mingw32/lib/ruby/gems/1.9.1"]
irb(main):003:0>

Notice that the version is not "1.9" but "1.9.1", this is
because it
uses RbConfig::CONFIG[''ruby_version''] to determine the version
of the
API compatibility layer.

FYI: 1.9.2-dev so far remains as 1.9.1.

So, with that in mind, wanted to replicate this into my "ruby
switching" scripts, which I lamely put here:

http://github.com/luislavena/binfiles/blob/master/rb18.bat
http://github.com/luislavena/binfiles/blob/master/rb19.bat

As you can see, pretty lame, but works.

Since I don''t have time right now to update my previous multiruby
scripts, used those batches for long time.

Anyhow, been trying to put this into Pik, but I''m stuck. Since
GEM_HOME should also be in the PATH (with \bin)... wonder:

Shouldn''t switch_path_to defer it''s writing and return the
resulting
PATH? In that way, I should be able to hook, under the same PATH of
GEM_HOME, instead of default to ENV[''PATH''] as is right now.

Comments? Suggestions?

Thank you!
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry

On Sun, Jun 21, 2009 at 12:16 PM, Luis Lavena<luislavena at gmail.com>
wrote:
> Hello Guys,
>
> I wanted to share my lovely experience so far using Pik...
>
> I just love it!
>
> Gordon: thank you for making by batch files (rb18 and rb19) deprecate
> so easily :-D
Thanks for trying it out!  Your input has been most helpful.
> Anyhow, been trying to put this into Pik, but I''m stuck. Since
> GEM_HOME should also be in the PATH (with \bin)... wonder:
>
> Shouldn''t switch_path_to defer it''s writing and return
the resulting
> PATH? In that way, I should be able to hook, under the same PATH of
> GEM_HOME, instead of default to ENV[''PATH''] as is right
now.
Have a look at the gem_home branch on github.

http://github.com/vertiginous/pik/commits/gem_home

I made some updates yesterday, and I think it will work like you need it to.

There are basically 3 more things I''d like to do before the next
release.
   #  Pik adds a line to the bottom of the pik.bat file that rubygems
generates.  I need to make this more robust.  In some edge cases, it
will end up adding multiple lines, which causes strange results.
   #  Make the ''add_gem_home'' command a little more user
friendly.
Right now you have to type in a path for each version of ruby that Pik
knows about.  There should be a "default" option that uses
Gem.default_path.first

  #  Wire up the --system flag.  This will make persistent changes to
the Windows environment.  It won''t make changes to other open command
sessions, but I''m fine with that.  I''ll just document it
thoroughly.
I''m waiting on this until I understand the way the current installers
write to system environment and/or user environment.

Please keep the feedback coming!
> Thank you!
And Thank you!
> --
> Luis Lavena
> AREA 17
> -
> Perfection in design is achieved not when there is nothing more to add,
> but rather when there is nothing more to take away.
> Antoine de Saint-Exup?ry
> _______________________________________________
> Rubyinstaller-devel mailing list
> Rubyinstaller-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rubyinstaller-devel
>

On Tue, Jun 23, 2009 at 1:30 PM, Gordon Thiesfeld<gthiesfeld at gmail.com>
wrote:
> On Sun, Jun 21, 2009 at 12:16 PM, Luis Lavena<luislavena at
gmail.com> wrote:
>> Hello Guys,
>>
>> I wanted to share my lovely experience so far using Pik...
>>
>> I just love it!
>>
>> Gordon: thank you for making by batch files (rb18 and rb19) deprecate
>> so easily :-D
>
> Thanks for trying it out! ?Your input has been most helpful.
>
Hehehe, besides being annoying ;-)
>> Anyhow, been trying to put this into Pik, but I''m stuck. Since
>> GEM_HOME should also be in the PATH (with \bin)... wonder:
>>
>> Shouldn''t switch_path_to defer it''s writing and
return the resulting
>> PATH? In that way, I should be able to hook, under the same PATH of
>> GEM_HOME, instead of default to ENV[''PATH''] as is
right now.
>
> Have a look at the gem_home branch on github.
>
> http://github.com/vertiginous/pik/commits/gem_home
>
> I made some updates yesterday, and I think it will work like you need it
to.
>
Please take a look to this patch:

http://pastie.org/523583

It ensures "run" works with the new gem_home format.

Now it does, and tweaks my PATH! ;-)

http://pastie.org/523585
> There are basically 3 more things I''d like to do before the next
release.
> ? # ?Pik adds a line to the bottom of the pik.bat file that rubygems
> generates. ?I need to make this more robust. ?In some edge cases, it
> will end up adding multiple lines, which causes strange results.
Yes, it seems is brittle.
> ? # ?Make the ''add_gem_home'' command a little more user
friendly.
> Right now you have to type in a path for each version of ruby that Pik
> knows about. ?There should be a "default" option that uses
> Gem.default_path.first
>
Hmn, good point. Also fix the specs since now I''m getting failures and
that is not very encouraging from this end to play with the code :-P
> ?# ?Wire up the --system flag. ?This will make persistent changes to
> the Windows environment. ?It won''t make changes to other open
command
> sessions, but I''m fine with that. ?I''ll just document it
thoroughly.
> I''m waiting on this until I understand the way the current
installers
> write to system environment and/or user environment.
>
There was a project by James Lawrence at GitHub that changed the
environment at the system level.

To be able to change all the running process (including the parent
process that fired ruby) you need the inject dll behavior, which is
not worthy.
> Please keep the feedback coming!
>
Will do! :D

Cheers,
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup?ry