Can I ensure a ruby version is active by default on Windows?

[Dan Wagner]

I would like to use uru to manage Ruby versions on Windows 8. Suppose I install uru, then:

• use the 2.0.0-p598 (x64) RubyInstaller to add a 2.0 version of Ruby to my system
• use the 2.1.4 (x64) RubyInstaller to add a 2.1 version of Ruby to my system

Taking care on both installs to NOT check the "Add Ruby executables to your PATH" box on each (as I'd like uru to handle that).

Using cmd.exe, I then run uru admin add <path to Ruby 200>\bin to put Ruby 2.0 under control, then uru admin add <path to Ruby 214>\bin to put Ruby 2.1 under control. So far, so good! I can activate the Ruby version I'd like to use and everything works like gangbusters.

If I were to restart cmd.exe, though, I would need to re-execute uru 200 or uru 214 or, if I had set up a .ruby-version file in my %UserProfile% directory, uru auto before a Ruby version was active again and I could get back to work.

Is there a way to configure uru such that a version of Ruby (of my choosing) is active when I start cmd.exe?

[Jon]

First, that's great you are not putting MRI on your PATH when installing via the RubyInstaller. I purposefully made the default path add optional when creating the installer in order to help prevent conflicts. Second, great to see you did not tell uru to make one of your MRI's a "system" ruby. I also prefer letting uru manage which ruby runtime is on PATH.

Uru cannot do the cmd.exe initialization you would like, but you can configure cmd.exe (and powershell via your user profile file) via a registry AutoRun value hack to execute uru 200 or uru 214.

I'm not sure if there is a non-registry way (a la the old autoexec.bat) to make cmd.exe automagically run uru upon startup.

I did a quick test by adding a REG_SZ HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun entry with uru 215 as the value, and it appears to work on my Win8.1 x64 system.

Microsoft Windows [Version 6.3.9600]
(c) 2013 Microsoft Corporation. All rights reserved.
---> Now using ruby 2.1.5-p273 tagged as `215p273-x32`

C:\Users\Jon\Documents>uru ls
    17161       : jruby 1.7.16.1 (1.9.3p392) 2014-10-28 4e93f31 on Java HotSpot(TM...
    200p598-x32 : ruby 2.0.0p598 (2014-11-13 revision 48403) [i386-mingw32]
 => 215p273-x32 : ruby 2.1.5p273 (2014-11-13 revision 48404) [i386-mingw32]

That said, I am very concerned with the AutoRun registry hack for three reasons:

1. We've seen AutoRun registry problems messing up native gem installs.
2. It will always run when you use cmd.exe and according to the MSFT doco, can run twice, once from an HKLM registry entry, and once from an HKCU entry. Perhaps you can limit this broad scope but having the AutoRun entry run a custom .bat wrapper with some scope limiting magic, but this seems risky.
3. Depending upon how often you update your MRI install registrations (or change the tag labels), you could be continually updating your AutoRun entry in order to keep things working. Say you put uru 214 in AutoRun. When uru can't find a ruby matching 214 (either you deregistered 214 or tweaked the tag labels), you'll need to update the AutoRun entry appropriately.

I don't have any good recommendations on this one for cmd.exe usage other than try the AutoRun registry hack and see if you can break things (do a gem i redcarpet or other native gem install) before counting on it.

I am going to close this one as it's not a direct uru issue. That said, I am curious as to what you choose. Please update the closed issue with your results once you've tested things out, or re-open if you discover a uru bug.

[Jon]

Closing. This is primarily a shell config issue rather than an uru issue.

[Dan Wagner]

Hey @jonforums -- thank you so much for not only answering the question but for also providing support on shell configuration.

After reading through those links I think the downsides of an AutoRun registry hack outweigh the convenience. Instead, this can be addressed with process the same way bundler can be used to stay out of dependency purgatory.

That means on projects:

• Will this need to be compiled to an .exe with ocra? If so, .ruby-version => 20x, if not .ruby-version => 21x.
• uru auto
• bundle init
• ...

And whenever resuming work on a project:

• uru auto
• bundle install
• ...

Thanks again and keep fighting the good fight with uru -- us Windows-users appreciate it massively!

[Jon]

@danwagnerco I also like .ruby-version for per-project default ruby runtime activation. Glad to hear uru's impl works for you, and these early versions of uru are solid enough to be useful to you.

While it will never be bundler, you may be interested in the "isolated project gemset" feature I want to add once I clear a few things off my TODO list. I'll be interested in getting your usage feedback once there's something to play with.

[Dan Wagner]

Hey @jonforums -- had a minute this morning to read through the linked conversation with @luislavena on the isolate project gemset feature feature you described above. Sounds like a great idea, and the A/B scenarios you describe in the last post are about as friendly as one could ask for. Looking forward to kicking the tires on that!

[Kunigunda Kucerova]

Thank you for the great information here.

I want to add one more piece to the puzzle: If you add

 REG_SZ HKEY_CURRENT_USER\Software\Microsoft\Command Processor\AutoRun

entry with uru 215 as the value.

Then you have to maintain it in the registry. I can recommend having uru auto in the AutoRun key as a value. You have to then maintain it in your %profile% .ruby-version -> e.g.222p95. Then you will have only one place to maintain and you can leave the registry alone. I have tested it on my win7 x64 will all the SP1 & patches from M$ and native gems installs without a hiccup.