[Rubyinstaller-devel] Pik and GEM_HOME, GEM_PATH and my environment

Luis Lavena luislavena at gmail.com
Wed Jun 24 18:36:33 EDT 2009

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:


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

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


> 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

Luis Lavena
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

More information about the Rubyinstaller-devel mailing list