Fall back to other binary in PATH if gem-installed binary not installed in current ruby

[gerrit]

I‘ve got a binary (installed by npm) in /usr/local/bin/lessc that I would like to use some of the time. But for some Ruby projects I‘m using the LESS gem which installs a binary in ~/.rbenv/shims/lessc.

~/.rbenv/shims is before /usr/local/bin in my PATH.

I’d like to be able to use the gem-provided binary when I‘m using a ruby version where it is installed, and otherwise (default case for me) fall back to /usr/local/bin/lessc.

Currently, I get the message

`rbenv: lessc: command not found

The lessc' command exists in these Ruby versions: 1.9.2-p290

and the only way to use the npm-provided binary by specifying the whole path. It seems to me that the shim binary should fall back to other binaries that are in the PATH already if nothing is installed in the current ruby.

[zol]

I second this motion. I'm having the same problem after having installed the heroku toolbelt, and having the heroku gem installed in one of my ruby versions.

Whilst the message telling me that the command exists in another version can be helpful, in this case it's preventing me from calling the correct binary.

[mislav]

I definitely agree; unfortunately I have no ideas how to approach solving this issue. This requires group thinking /cc @sstephenson @sheerun

[sstephenson]

Ref. #276.

[sheerun]

Add ~/.rbenv/defaults with command - ruby version map?

[mrak]

pyenv by @yyuu, which is a python version handler based off of rbenv already has this fallback functionality. Perhaps take a look at his project?

Check the pyenv global section of his README.md about pushing/popping versions of python

[yyuu]

The current master of pyenv is based on rbenv 0.4.0, all you here will feel very familiar to the code :)

Yep, pyenv can fallback to secondary (or tertiary, or more) versions to look up specified command. The significant changes are in pyenv-which.

I created my patch for rbenv-which as issue187 to allow looking up commands outside from rbenv. If it seems fine, I'd like to send it new pull request.

[yyuu]

I created the modification to the rbenv-which as a plugin rbenv-which-ext. This plugin allows rbenv to find commands not installed in rbenv.

Also, I discarded the issue187 branch because it corrupts the tests of rbenv.

[ianheggie]

Thanks yyuu, the plugin rbenv-which-ext fixed a problem I had with vagrant as a system binary, but having a clone of a project that includes vagrant as a gem and thus triggers a shim.

Can this be considered for inclusion into rbenv itself after all the plugin callbacks have executed?

[CpuID]

+1 for this feature, I just created a patch from yyuu@975f4dc and applied it locally and it ticked the boxes for my use.

[benwoodward]

+1 Having the same issue with heroku-toolbelt

[mislav]

@benwoodward and others: If you have a problem with vagrant or heroku commands, use rbenv whence to find which Ruby versions have installed gems for those projects, uninstall those gems and rbenv rehash.

Vagrant and Heroku toolbelt have a runtime environment that is supposed to be isolated from the Rubies and gems installed for development. This concept is ruined if you have vagrant or heroku gems installed anywhere, so you'd best uninstall them.

[royzinn]

Please excuse me if it's the wrong issue, but I did what @mislav suggested and uninstalled heroku from all rubies (after rbenv whence).
I then installed the heroku-toolbelt and I keep getting the error: 'rbenv: heroku: command not found'
I also tried manually installing the heroku gem but getting other errors.

When doing which heroku I get '/Users/royzinn/.rbenv/shims/heroku'

Is there any suggestion on how to make the heroku command live again? (BTW - it all started after installing new ruby version and trying to run the heroku command on it, it worked fine for previous ruby versions)

Thanks,
Roy

[benwoodward]

@royzinn I had exactly the same issue. Installing @yyuu's https://github.com/yyuu/rbenv-which-ext fixed it for me.

[royzinn]

Thanks a lot @benwoodward I will give it a try.
I actually did something which worked and I hope it didn't break anything else, so I would love to hear thoughts on this. I symlinked heroku into rbenv/shims/heroku and it seems to be working, is it a good approach?

[mislav]

@royzinn Did you rbenv rehash after you uninstalled heroku gem from every version? That should get rid of /Users/royzinn/.rbenv/shims/heroku

[royzinn]

@mislav - yes I did. But just to be on the safe side,I did hat in the local ruby version (rbenv local) I was at.
Still after doing that, when I ran the 'which heroku' command it was showing the one under rbenv/shims
I had to remove the folder manually and them symlinked

[mislav]

Symlinking heroku into rbenv/shims/heroku will work for a short while but will get rewritten the next time something runs rbenv rehash, so you can't count on it as a permanent solution.

If you did rbenv rehash, and the heroku shim is still in rbenv, that means that some Ruby version still has the Heroku gem. Please run this in your shell:

for ver in $(rbenv whence heroku); do RBENV_VERSION="$ver" gem uninstall -a -x heroku; done
rbenv rehash

[macek]

👍 for @yyuu's plugin: https://github.com/yyuu/rbenv-which-ext

[Bastes]

Another 👍 for @yyuu's plugin (https://github.com/yyuu/rbenv-which-ext)

[fwuensche]

@mislav's last comment worked like a charm for me.

[rickard-von-essen]

👍 for this, I think it should be the default behaviour not requiring a plugin.

If you have a problem with vagrant or heroku commands, use rbenv whence to find which Ruby versions have installed gems for those projects, uninstall those gems and rbenv rehash.

Vagrant and Heroku toolbelt have a runtime environment that is supposed to be isolated from the Rubies and gems installed for development. This concept is ruined if you have vagrant or heroku gems installed anywhere, so you'd best uninstall them.

@mislav not very useful if you from time to time do patches on Vagrant and therefore want to have it installed from gem when developing, but not in everyday uses since it's a pain to handle plugins etc. when running as a gem.

[kamronbatman]

This problem actually makes rbenv very dangerous. It is routine for people to download repos and run them for their specific needs. If Ruby is not your sole (or primary) tech stack, you can get major problems. Example that happened to me.

Cloned a repo and ran it. It installed the required gems for the required Ruby version. rbenv created shims for them. In this case, the chromedriver binary was installed via chromedriver-helper.

Even though I do not normally use that Ruby version or that repo, the shims are global none-the-less. When I ran my e2e tests from another tech stack (webpack/selenium/etc), it ran chromedriver, which gave the rbenv: command not found under the hood. Rbenv did not send a failure signal and the selenium server thought it was running properly. This meant my tests were timing out and I could not easily find out why.

Suffice to say I wasted way too much time thinking my primary tech stack was broken, and fiddling with my primary installation of chromedriver before I realized rbenv was the source of the problems.

It is unnecessary, dangerous, and frankly unacceptable that it is recommend that rbenv be set up in such a way that it hijacks PATH, uses global shims, does not properly send failure signals, and does not look up system commands for a passthrough.

It is also unacceptable that this issue has been around since 2012 with no integrated fix and instead relies on a plugin from 2013 with only 11 stars and virtually no visibility for other users to find it.

[mlh758]

Just ran into this problem on a server managed with chef. Uninstalled the passenger gem because we're now using a newer version provided by the passenger yum repo. Unfortunately the passenger gem was also installed on an older version of ruby on the server and instead of using passenger-status in /usr/sbin/ it's still referencing a shim in the old ruby version and throwing an error.

rbenv rehash also throws an error now.

Edit: rbenv rehash was just the lock file being left over from a previously failed rehash.