- edited description
Remove system Ruby from PATH when switching Ruby versions.
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.
Comments (8)
-
reporter -
repo owner 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 configuredPATH
and only prepends components to your existingPATH
in order to provide its ruby switching capabilities. While this behavior minimizes the chance thaturu
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 originalPATH
) 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.
-
reporter 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 doesuru 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?
-
repo owner Uru considers any ruby that it does not explicitly add to
PATH
to be a "system" ruby. Specifically, any ruby that has been put onPATH
(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 aPATH
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 existingPATH
that contains the location of your system ruby. Since uru's activated ruby location is before your system ruby onPATH
, uru effectively overrides your system ruby. When you ask uru to deactivate a registered ruby (i.e. -uru nil
oruru sys
), uru simply removes thePATH
chunk it prepended to your originalPATH
thereby restoring your originalPATH
that still contains the system ruby you or your package manager added. Uru does not try to interpret your originalPATH
.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.
-
reporter 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:
- 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.
- If no installation of Ruby is on my PATH when I launch Atom, the linting plugin doesn't work properly
- My project uses an uru-managed version of Ruby, not the version used by Atom.
- 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? -
repo owner 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. -
reporter Yeah, that's probably what I'll end up doing. Thanks.
-
reporter - changed status to wontfix
- Log in to comment