-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Causes Issues with Yarn shims #29
Comments
I'm having exactly the same issue and while I was googling it I came here. @westonganger Did you try to debug it? Did you find any solution? |
Nope I just removed the plugin. TBH I dont like yarn anyways but its required for some stuff still. Would much prefer to continue using this plugin if a fix is made. |
I did some debugging and I found out that if you did not generate binstubs for your project, then rbenv-binstubs generates shims for all files in I'm not sure if this plugin should do it or not, but you can avoid it by generating binstubs for all of your projects with:
Once you do it the issue with the Btw. this is mentioned also in the README of this project but I never paid attention to it. |
Yes, rbenv-binstubs was specifically designed to work with binstubs generated by bundler, whose default path is set to From https://bundler.io/man/bundle-binstubs.1.html
This is unless BUNDLE_BIN is set. This tells bundler (and rbenv-binstubs) where to put / find executables. Usually, when I use rbenv-binstubs, I also configure bundler as follows: bundle config --global path .bundle
bundle config --global bin .bundle/bin which makes all projects have completely isolated gems and binstubs in their There may be some value in having the plugin detect whether a binstub is a ruby executable or not before generating shims. I did this specifically for pyenv-binstubs and may consider implementing here, but it's at the bottom of my priorities. Also, I'm not sure if bundler also puts compiled executables in the binstub path, in which case, I wouldn't know how to handle it. |
This issue should be resolved in madumlao/rbenv-binstubs@335a830 (master branch). rbenv-binstubs will now only shim / inject ruby executables. Would appreciate if you checked it out! |
Thank you @madumlao! Unfortunately I'm not able to reproduce the original issue anymore so I can't test if the new version fixes it. |
@madumlao I'm curious about your implementation. The yarn binstub that ships with Rails (or is generated by Rails, rather) is a ruby binstub:
Did this not used to be the case? Or is there something else about your implementation that I'm missing? I suspect the former, and that this patch is no longer necessary for yarn in particular, but would be necessary for any other bin/* utility that isn't a ruby executable? |
@jasonkarns , that's weird. Rails should NOT be either shipping with, generating, or stubbing yarn. I also checked my old rails projects and they don't stub yarn either. Yarn is not a rails utility and this might cause serious issues with users of nodenv / nenv. |
The yarn binstub was first introduced in Dec 2016: rails/rails@3dac36b#diff-835c0a70de9cf02b472c84bf0a72323a and later renamed as a .tt template: rails/rails@8dd76a7#diff-de7ecbe89c4176f75b702a1db707794b |
@jasonkarns , since I encountered a similar issue in nenv because the node community just LOVES creating executables that "shadow" system executables. So, I've tried a different tack in madumlao/rbenv-binstubs/unshadow . This is also merged into madumlao/rbenv-binstubs/master rbenv-binstubs will actively "unshim" if no binstubs are pointed to by any shimmed executables, thus defaulting to whatever system or user-defined paths are defined. This should solve the case where yarn being shimmed inside the project path of one ruby project causes yarn to break everywhere else (rbenv will not use the shim if the yarn executable pointed to by the shim does not exist). However, inside the project path of that ruby project, the yarn shim will still be used. This does not resolve any issues caused by that yarn shim being broken (if it is broken). |
This plugin was causing problems with yarn making it unusable
I stumbled across rbenv/rbenv#1051 (comment) in which someone commented to remove this plugin and it fixes the problem
Sure enough, removing this plugin
rm -rf ~/.rbenv/plugins/rbenv-binstubs
fixed the issue immediately. In my case I am using OSX Sierra but this fix could likely apply to other systems.The text was updated successfully, but these errors were encountered: