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

Open
gerrit opened this Issue Feb 2, 2012 · 21 comments

Comments

Projects
None yet

gerrit commented Feb 2, 2012

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 commented Aug 24, 2012

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.

Collaborator

mislav commented Dec 13, 2012

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

Collaborator

sstephenson commented Dec 13, 2012

Ref. #276.

sheerun commented Jan 10, 2013

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

mrak commented May 8, 2013

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 yyuu pushed a commit to yyuu/rbenv that referenced this issue May 13, 2013

Yamashita Yuu lookup commands from original `$PATH` if it is not installed in rbenv ( 975f4dc
Contributor

yyuu commented May 13, 2013

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.

Contributor

yyuu commented May 21, 2013

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.

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 commented Dec 9, 2013

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

+1 Having the same issue with heroku-toolbelt

Collaborator

mislav commented Feb 4, 2014

@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 commented Feb 5, 2014

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

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

royzinn commented Feb 5, 2014

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?

Collaborator

mislav commented Feb 5, 2014

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

royzinn commented Feb 5, 2014

@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

Collaborator

mislav commented Feb 5, 2014

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

Bastes commented May 25, 2014

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

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

👍 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment