pik version 0.0.2 has been released!
* <http://github.com/vertiginous/pik/tree/master>
* <Gordon Thiesfeld>
PIK is a tool to switch between multiple versions of ruby on Windows.
You have to tell it where
your different ruby versions are located using ''pik add''.
Then you
can change to one by using
''pik switch''.
It also has a "sort of" multiruby functionality in ''pik
run''.
== FEATURES/PROBLEMS:
Currently, changes are to the open cmd session only. I haven''t
wired up the --global switch yet.
Specs are very incomplete.
''pik config'' could be dangerous. Use only if you know what
you''re doing.
Only works on CRuby at present.
== SYNOPSIS:
pik commands are:
add Add another ruby location to pik.
checkup Checks your environment for current Ruby best practices.
run Runs command with all version of ruby that pik is aware of.
rm Remove a ruby location from pik.
switch Switches to a different version.
help Diskplays help topics.
For help on a particular command, use ''pik help COMMAND''.
Example:
C:\>pik run "gem in hpricot --no-ri --no-rdoc"
== Running with 185: ruby 1.8.5 (2006-12-25 patchlevel 12)
[i386-mswin32] = Successfully installed hpricot-0.8.1-x86-mswin32
1 gem installed
== Running with 186: ruby 1.8.6 (2008-08-11 patchlevel 287)
[i386-mswin32] = Successfully installed hpricot-0.8.1-x86-mswin32
1 gem installed
== Running with 186: ruby 1.8.6 (2009-03-31 patchlevel 368)
[i386-mingw32] = Building native extensions. This could take a while...
Successfully installed hpricot-0.8.1
1 gem installed
== Running with 191: ruby 1.9.1p0 (2009-01-30 revision 21907)
[i386-mingw32] = Building native extensions. This could take a while...
ERROR: Error installing hpricot:
ERROR: Failed to build gem native extension.
... Errors because I haven''t added the devkit ...
== Running with 191: ruby 1.9.1p129 (2009-05-12 revision 23412)
[i386-mingw32] = Building native extensions. This could take a while...
Successfully installed hpricot-0.8.1
1 gem installed
== REQUIREMENTS:
Windows, Ruby, Rubygems
== INSTALL:
1. gem install pik (currently only on github as vertiginous-pik)
2. pik add path_to_ruby_bin
3. repeat step 2 as many times as necessary,
or use ''pik add -i''
4. pik run "gem install pik"
Changes:
### 0.0.2 / 2009-06-02
* several minor enhancements
*updated help messages
*updated readme
*some formatting of output
* <http://github.com/vertiginous/pik/tree/master>
* <Gordon Thiesfeld>
On Tue, Jun 2, 2009 at 7:03 PM, Gordon Thiesfeld <gthiesfeld at gmail.com> wrote:> pik version 0.0.2 has been released! > > * <http://github.com/vertiginous/pik/tree/master> > * <Gordon Thiesfeld> > > PIK is a tool to switch between multiple versions of ruby on Windows. > You have to tell it where > ?your different ruby versions are located using ''pik add''. ?Then you > can change to one by using > ?''pik switch''. > > ?It also has a "sort of" multiruby functionality in ''pik run''. >Awesome work Gordon! I just switch from my arcane batch files and DLL injector in FreeBASIC to pik! Also, I''ve started to open Issues on GitHub to keep track of what I find from this side of the line (hope you don''t mind).> > == FEATURES/PROBLEMS: > > ?Currently, changes are to the open cmd session only. ?I haven''t > wired up the --global switch yet. >Doing system wide can be tricky, or propagate that change to the whole environment requires some DLL injection. Right now I only need to have one ruby in the PATH to be able to fire it, which is cool :-)> ?Specs are very incomplete. >Maybe I can help you out on that front ;-) Again, awesome work man and thank you for sharing this. PS: Please post to Ruby-Talk, lot of folks will rejoice from using this! -- 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 Wed, Jun 3, 2009 at 2:41 AM, Luis Lavena <luislavena at gmail.com> wrote:> On Tue, Jun 2, 2009 at 7:03 PM, Gordon Thiesfeld <gthiesfeld at gmail.com> wrote: >> pik version 0.0.2 has been released! >> > > Also, I''ve started to open Issues on GitHub to keep track of what I > find from this side of the line (hope you don''t mind).Not at all! That''s why I posted here first. I want to iron things out before I release it to the masses ;-)> > Doing system wide can be tricky, or propagate that change to the whole > environment requires some DLL injection. >I''m not sure what you mean here. My plan is to update the local session via batch file, and the whole Windows environment via WIN32OLE. I also plan to use ftype and/or assoc commands to update things. Is there a flaw in doing it this way? Am I missing something? I don''t know how to update icons (at least automatically), but I don''t know if that''s something I care about or not ;-)> Right now I only need to have one ruby in the PATH to be able to fire > it, which is cool :-) > >> ?Specs are very incomplete. >> > > Maybe I can help you out on that front ;-)That would be great!> > Again, awesome work man and thank you for sharing this. > > PS: Please post to Ruby-Talk, lot of folks will rejoice from using this!I plan to post it, possibly over the weekend. I am hoping the fine folks on this list will put it through its paces first. This could potentially wreck someone''s ruby install, so I want to make sure it''s fairly solid/stable. Thanks for the feedback! Gordon
> I just switch from my arcane batch files and DLL injector in FreeBASIC to pik!why is DLL injection necessary? Just wondering. -=r
> I''m not sure what you mean here. ?My plan is to update the local > session via batch file, and the whole Windows environment via > WIN32OLE. ?I also plan to use ftype and/or assoc commands to update > things. ?Is there a flaw in doing it this way? ?Am I missing > something? ?I don''t know how to update icons (at least automatically), > but I don''t know if that''s something I care about or not ;-)Interesting. I might well end up using this :) I wonder if one difficulty is that currently open console windows remain fixed to the old ruby version. If that is the case, I then wonder if it would be possible to have something like... c:\ruby\bin containing ruby.bat gem.bat run_ruby_gem_command.bat # this one takes a parameter you could always just leave c:\ruby\bin in your path, and rewrite the .bat files depending on which ruby you''d like to next use. run_ruby_gem_command would be like run_ruby_gem_command mongrel or what not. Just thinking out loud! -=r
On Sat, Jun 6, 2009 at 7:50 AM, Roger Pack<rogerdpack at gmail.com> wrote:> Interesting. > I might well end up using this :) > > I wonder if one difficulty is that currently open console windows > remain fixed to the old ruby version.Pik already updates the currenlty open console window by updating the path to the new version. C:\>pik sw 185 && ruby -v && rake -V Switching to 185: ruby 1.8.5 (2006-12-25 patchlevel 12) [i386-mswin32] ruby 1.8.5 (2006-12-25 patchlevel 12) [i386-mswin32] rake, version 0.8.7 C:\>pik sw 186 mingw && ruby -v && rake -V Switching to 186: ruby 1.8.6 (2009-03-31 patchlevel 368) [i386-mingw32] ruby 1.8.6 (2009-03-31 patchlevel 368) [i386-mingw32] rake, version 0.8.7 C:\>pik sw 191 p129 && ruby -v && rake -V Switching to 191: ruby 1.9.1p129 (2009-05-12 revision 23412) [i386-mingw32] ruby 1.9.1p129 (2009-05-12 revision 23412) [i386-mingw32] rake, version 0.8.7 The --global switch will update the local session path and the whole Windows environment.> > If that is the case, I then wonder if it would be possible to have > something like... > > c:\ruby\bin containing > ?ruby.bat > ?gem.bat > ?run_ruby_gem_command.bat # this one takes a parameter > > you could always just leave c:\ruby\bin in your path, and rewrite the > .bat files depending on which ruby you''d like to next use. > > run_ruby_gem_command would be like run_ruby_gem_command mongrel > or what not. > > Just thinking out loud! > -=r > _______________________________________________ > Rubyinstaller-devel mailing list > Rubyinstaller-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubyinstaller-devel >
> Pik already updates the currenlty open console window by updating the > path to the new version.Cool. Does it update other currently open console windows to the newest version? -=r
On Sat, Jun 6, 2009 at 9:09 AM, Roger Pack<rogerdpack at gmail.com> wrote:>> Pik already updates the currenlty open console window by updating the >> path to the new version. > > Cool. Does it update other currently open console windows to the newest version?Ah, no. That it can not do.> -=r > _______________________________________________ > Rubyinstaller-devel mailing list > Rubyinstaller-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/rubyinstaller-devel >
On Sat, Jun 6, 2009 at 11:21 AM, Gordon Thiesfeld<gthiesfeld at gmail.com> wrote:> On Sat, Jun 6, 2009 at 9:09 AM, Roger Pack<rogerdpack at gmail.com> wrote: >>> Pik already updates the currenlty open console window by updating the >>> path to the new version. >> >> Cool. Does it update other currently open console windows to the newest version? > > Ah, no. ?That it can not do. >And that''s why I mentioned the DLL injection thing. I''ve used in the past a small dll that I inject into other process to see and alter those process environments. Without that, you can''t change their environments unless you fire a system-wide event and listen to one specific message. -- 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
> If that is the case, I then wonder if it would be possible to have > something like... > > c:\ruby\bin containing > ?ruby.bat > ?gem.bat > ?run_ruby_gem_command.bat # this one takes a parameterI like pik it has a nice interface. To clarify the suggestion, it was [to implement --global option] create something like c:\ruby_generic_bin # always stays at the first of the path when you do ruby switch some_version it clears, then propagates c:\ruby_generic_bin with .bat files to call back to the "right" executable/batch files within the currently selected ruby''s bin folder. Then other command windows will be updated, and also it has persistence from session to session. If it sounds agreeable I could code it up in my fork. Thoughts? =r