Remove system Ruby from PATH when switching Ruby versions.

[Ajedi32]

Currently, when you have a system Ruby setup with uru, switching to another Ruby version only adds that version to the front of your PATH; it doesn't remove the existing system Ruby from the PATH. This can create problems, as executables which aren't overridden by the new Ruby installation will still be available in the shell, but they'll be executables from the old Ruby version.

When switching away from the system Ruby, uru should remove the system Ruby from the PATH, and restore it upon switching back.

[Jon]

Uru makes few assumptions about your system. Uru is also designed to place few requirements on your system; uru assumes that you know best how to manage your environment. As such, uru does not muck with your configured PATH and only prepends components to your existing PATH in order to provide its ruby switching capabilities. While this behavior minimizes the chance that uru will conflict with your unique environments, there are tradeoffs.

The system ruby (i.e. - a ruby, one that uru does not manage, that you have hard coded on your original PATH) issue you raise is one of those tradeoffs.

While I see some benefits to supporting a system ruby, I recommend not using a system ruby especially if it causes conflicts in your unique system environment.

[Ajedi32]

I can understand the desire to try to keep things as simple as possible, but my expectation was that the whole point of uru admin add system was to make uru manage the system Ruby. If that's not what it does, what does uru admin add system do?

While I use uru to manage my development environments, other applications (even some non-CLI apps) on my system use the system Ruby, so I can't simply remove it from my PATH. Having the system Ruby remain on my PATH however after I thought I'd switched away from it with uru was rather confusing for me, and caused some problems with my development environment.

To illustrate my point about why this is confusing:

$ uru list
    193p551     : ruby 1.9.3p551 (2014-11-13) [i386-mingw32]
    223p173     : ruby 2.2.3p173 (2015-08-18 revision 51636) [x64-mingw32]
 => system      : ruby 2.3.0p0 (2015-12-25 revision 53290) [i386-mingw32]

The system Ruby is selected. Let's select a different ruby version:

$ uru 223
---> now using ruby 2.2.3-p173 tagged as `223p173`

$ uru list
    193p551     : ruby 1.9.3p551 (2014-11-13) [i386-mingw32]
 => 223p173     : ruby 2.2.3p173 (2015-08-18 revision 51636) [x64-mingw32]
    system      : ruby 2.3.0p0 (2015-12-25 revision 53290) [i386-mingw32]

Now the new Ruby version is selected, and, importantly, the system Ruby isn't selected anymore. So why are both still on my PATH?

Is there any reason why uru would have difficulty correctly managing a system Ruby compared to how it handles the other Ruby environments?

[Jon]

Uru considers any ruby that it does not explicitly add to PATH to be a "system" ruby. Specifically, any ruby that has been put on PATH (e.g. - by your package manager or in your shell config) is a system ruby.

Uru does not treat system rubies like the rubies it does manage. Uru has no business mucking with system rubies (or other parts of your PATH) managed outside of uru. That is your job as the maintainer of your system.

That said, I considered it a convenience for uru to minimally understand system rubies, and implemented bare bones support for system rubies. Once you explicity tell uru you have a system ruby already on your PATH, it will behave as shown in your example.

However, uru will never munge the part of your PATH that exists before using uru to activate a registered ruby. Uru works with system rubies by prepending a PATH chunk (e.g. - _U1_;C:\Apps\rubies\ruby-2.3\bin;_U2_; or _U1_:/home/me/.gem/ruby/2.3.0/bin:/home/me/.rubies/ruby-2.3/bin:_U2_:) to your existing PATH that contains the location of your system ruby. Since uru's activated ruby location is before your system ruby on PATH, uru effectively overrides your system ruby. When you ask uru to deactivate a registered ruby (i.e. - uru nil or uru sys), uru simply removes the PATH chunk it prepended to your original PATH thereby restoring your original PATH that still contains the system ruby you or your package manager added. Uru does not try to interpret your original PATH.

I suspect the problem you are seeing with your dev environment (gems and DLLs existing in your windows system ruby but not your uru managed ruby??) are another example of why I suggest not using a system ruby.

Uru's bare bones convenience support does not mean management of system rubies. It is outside uru's scope to manage system rubies.

[Ajedi32]

Yeah, I understand the underlying design decisions, I guess I'm just wondering what the best way is to support the following use case with uru, given those constraints:

1. I have a GUI application, Atom, which, as part of a linting plugin for Ruby code, uses the version of Ruby on my PATH to validate the syntax of Ruby files. Atom is launched from my desktop, not terminal, so I'm currently unable to use uru to manage the version of Ruby used by Atom.
2. If no installation of Ruby is on my PATH when I launch Atom, the linting plugin doesn't work properly
3. My project uses an uru-managed version of Ruby, not the version used by Atom.
4. If both the uru-managed Ruby and system Ruby are on my PATH at the same time, my project fails to run. (I wasn't able to determine the exact reasons for this in a reasonable amount of time, but removing the system Ruby from my PATH and only using the uru-managed version fixes the problem.)

The TL;DR of that is that one GUI application I use requires a system Ruby, but my project itself requires only the uru-managed version of Ruby to be on my PATH when I run it.

Maybe the easiest solution is to just remove the system Ruby from my PATH using my .bashrc file, so it's there in the GUI but not the terminal?

[Jon]

What about creating wrapper to launch atom, i.e. - a custom desktop launcher (or shortcut on windows) that calls a script that sets PATH to include a ruby before launching atom?

The atom process should see your system ruby which will allow the linter to work. You also remove that system ruby from PATH from your ~/.profile or ~/.bashrc. You then use uru to manage rubies when using bash to work with your project.

[Ajedi32]

Yeah, that's probably what I'll end up doing. Thanks.