Bundler and Wrong Binstubs

Bundler and wrong binstubs?

What worked for me was

rm -rf bin/*

Then open a new terminal session and

bundle exec rake app:update:bin

How to prevent bundler from generating binstubs?

Bundler generates binstubs on a per-application basis. If you ran bundle install --binstubs at some point in the past, Bundler will remember that and generate binstubs anytime you run install again. To disable them, you can either run bundle install --no-binstubs, or run rm -rf .bundle/config. Either way, that will disable binstub generation.

rbenv, bundler, binstubs… confusion

If you are using your gem in another project and you installed it using bundler you have to stick with bundle exec myexec. To use your gem system wide you should install it using the gem command and rbenv rehash your environment.

I hope this helps, otherwise it would be nice if you provided some more information how you are using bundler etc.

What does bundle install --binstubs serve for us?

From bundle install --help man page

--binstubs[=<directory>]
Creates a directory (defaults to ~/bin) and place any executables from the gem there. These executables run in Bundler's context. If used, you might add this directory to your
environment's PATH variable. For instance, if the rails gem comes with a rails executable, this flag will create a bin/rails executable that ensures that all referred depen-
dencies will be resolved using the bundled gems.

Should I use `bundle exec` or Rails' binstubs?

tl;dr no particular difference, but if I were to choose, I'd use bin/rails

There's little to no difference. Let us see.

DISABLE_SPRING=1 bin/rails --version:

bin/rails: require_relative '../config/boot'


config/boot: require 'bundler/setup'


bundler/setup: Bundler.setup


Bundler.setup: definition.validate_runtime!


Bundler.definition: Definition.build


Bundler::Definition.build: Dsl.evaluate


Bundler::Dsl.evaluate: builder.eval_gemfile


Bundler::Dsl#eval_gemfile: instance_eval

After require 'bundler/setup', trying to gem 'rails', 'x.y.z' results in:

*** Gem::LoadError Exception: can't activate rails (= x.y.z), already activated rails-5.1.3. Make sure all dependencies are added to Gemfile.

With bundle exec rails --version, we end up running bin/rails anyway:

~/.gem/ruby/x.y.z/bin/rails: load Gem.activate_bin_path('railties', 'rails', version)


exe/rails: require 'rails/cli'


rails/cli: Rails::AppLoader.exec_app


Rails::AppLoader.exec_app: `exec RUBY, 'bin/rails', *ARGV

Also, do note the message one can found in the last file:

Beginning in Rails 4, Rails ships with a rails binstub at ./bin/rails that should be used instead of the Bundler-generated rails binstub.

So, at the end of the day there's no difference. But considering the fact that Rails goes through the trouble of shipping its own binstubs, I'd favor bin/rails alternative. Also, it autocompletes better.

And,

App executables now live in the bin/ directory: bin/bundle, bin/rails, bin/rake. Run rake rails:update:bin to add these executables to your own app. script/rails is gone from new apps.

Running executables within your app ensures they use your app's Ruby version and its bundled gems, and it ensures your production deployment tools only need to execute a single script. No more having to carefully cd to the app dir and run bundle exec ....

Rather than treating bin/ as a junk drawer for generated "binstubs", bundler 1.3 adds support for generating stubs for just the executables you actually use: bundle binstubs unicorn generates bin/unicorn. Add that executable to git and version it just like any other app code.

https://github.com/rails/rails/blob/4-0-stable/railties/CHANGELOG.md

Your binstub at ./bin/rails was generated by Bundler instead of Rails

The solution is right there:

rails app:update:bin

Bundler binstubs directory is in the current directory

You could probably just reconfigure bundler to not use the root project directory for binstubs, assuming you don't need that for anything, by removing that line from .bundle/config.



Related Topics



Leave a reply



Submit