I know that bundler makes a gems executables available using the bundle exec command. I want to understand how I can call these executables from inside a controller action or model class method? I don't see anything about this in the Bundler doco.
Executables are ruby scripts sitting in the bin directory of the gems and their behavior depend on each gem. They are wrappers around the gems classes/APIs: simply dig into the source code of the gems you target and mimic the behavior of their CLIs.
Related
I used to use rvm and I want to start trying out rbenv.
From what I understand, rbenv does not have the same isolation built in when it comes to gems, it is only managing your ruby versions.
I know there is a rbenv addon that handles gems, but I dont' NEED to get it correct?
I can still download gems locally to my project and use bundle exec for each command?
Is there a short cut that I don't have to be so verbose when typing my commands?
Please explain the workflow as I dont' want to assume anything.
Update
I'm confused how to get the gems loaded into a separate folder.
Here's what I recommend:
Use rbenv for multiple Ruby version management, no customizations needed
a ruby installer plugin is now included with rbenv
it also handles ruby executable shims automatically, don't need to rbenv rehash anymore
it loads really fast (rvm has a noticable load time on shell startup)
Use bundler to dynamically resolve gems at runtime (options below)
it's fast enough anyways
don't need a special gem solution, bundler comes included /w Ruby now
Options to invoke bundler dynamically (I recommend the last one):
use bundle exec in front of every ruby executable
variant: create alias be='bundle exec'
create bundle binstubs <LIST GEM EXECUTABLES YOU WANT> for each project
use bin/ in front of every ruby executable to call the binstubs
do #2 and then set up .git/safe
lets you manually allow PATH lookups to the bin/ folder while in that project root
don't need to type bin/ anymore
Now multiple gem versions will all be installed into the same Ruby version bucket, and you let bundler dynamically add the right versions to the load path before every startup.
I am new to Ruby, Rails and gem management. One thing what I have noticed is that whenever I run bundle install (even within the project directory) it seems to install gems which affects other gem based Rails projects too.
For instance, assume that after running bundle install within one gem based Rail project (which installs a bunch of gems from the gemfile) I run into gem incompatibility issues. Now, these issues will manifest in all the other gem based projects too and will present themselves everytime I attempt to rackup
My questions are:
1) Is there a way to localize this damage (gem version incompatibility) to the current project and not have other projects affected?
2) Is there a good way to obtain a compatible set of gems or is the only way to look at the gem dependencies on a gem-by-gem basis (look at the tree) and figure out the compatible ones? I seem to be wasting a lot of time on this and if I fix one something else seems to break.
Please let me know what I'm missing here or point me to resources.
Thanks
It sounds like you're missing use of bundle exec
Description
This command executes the command, making all gems specified in the Gemfile(5) available to require in Ruby programs.
Essentially, if you would normally have run something like rspec spec/my_spec.rb, and you want to use the gems specified in the Gemfile(5) and installed via bundle install(1), you should run bundle exec rspec spec/my_spec.rb.
bundle install will install gems to $GEM_HOME which is shared by any apps using the same ruby and can result in multiple versions of the same gem being installed (this is expected and normal). If you don't then also use bundle exec to load only the gem versions specified in your Gemfile you can get incompatibility errors or unexpected behavior as ruby doesn't know which version of a particular gem to require.
RVM, rbenv, and other ruby version managers are useful tools for both isolating gems per project (which isn't really necessary when also using bundler) and for allowing multiple ruby versions to be installed on the same machine (which is not handled by bundler and can be very useful when developing multiple apps with different ruby version requirements).
When I run a rails console using
rails console
everything is fine.
When I run a rails console using
bundle exec rails console
I get the following warning
Bundler is using a binstub that was created for a different gem.
This is deprecated, in future versions you may need to `bundle binstub my_gem` to work around a system/bundle conflict.
my_gem happens to be a gem that I've created that is completely unrelated and not used in the current project directory.
I've tried every solution in this question with no luck:
Bundler is using a binstub that was created for a different gem
I would appreciate any guidance on removing this warning or help understanding how binstubs work so that I can figure out what's going on.
Nowadays it's common for projects to have "specialized" versions of tools. E.g. in some projects the "rails" command may be expected to be run using "spring" (to start up faster).
So it's not uncommon to generate files in your project's 'bin' directory, and then use those versions when running commands, so e.g. instead of
bundle exec rails console
or
bundle exec spring rails console
you could simply expect the following to work correctly
bin/rails console
and not care whether the project needs spring or bundler or zeus or whatever.
So if you don't have 'bin/rails' in your project, you should generate one that suits the project, e.g. using
bin/rake rails:update:bin
If you don't already have bin/rake, you might have to use
bundle exec rake rails:update:bin
(so your bin/rake commands will also get a speedup from using spring)
Some people even put ./bin in their paths, so whenever they run rake (or whatever) they are actually running ./bin/rake if it exists.
Troubleshooting
for project specific tasks, use bin/* files, creating them if needed (e.g. using special rake tasks like in Rails or using bundle binstub <gemname>) - usually those have Bundler specific lines that will make Bundler happy.
for non-project gems (like your gem), find out where it is (e.g. which mygem) and check out it's contents - it's probably using e.g. "bundler/setup" which is confusing Bundler (because bundler expects a local Gemfile file). Maybe your gem is using bundler (it shouldn't if it's a "global" kind of tool and not a "project" tool).
Also, if you're using them, check if tools like RVM and .rbenv are correctly adding their stuff to your bin files (they usually need to setup specific paths)
If you still have questions, it's best to post the contents of the bin file causing problems - it's meant to be a plain Ruby file, so if there's something wrong, it's usually because of the file contents (and not anything else).
More info: https://github.com/sstephenson/rbenv/wiki/Understanding-binstubs
It happened in a project of mine. Because I ran bundle install with another ruby version.
Make sure your rvm is the correctly ruby version.
Ruby on Rails 4 introduced* the ./bin directory. Inside of ./bin are a few executables: bundle, rails, rake, setup, spring.
My questions are:
What do these executables do? Why do they exist?
When are they invoked?
Can I edit them? Why would I edit them?
I've read the source of these files, and I've tried to Google their purpose, but I can't wrap my head around it. I'm looking for an in-depth explanation.
*I believe many of these files existed before Rails 4, just in different location.
Introduced in Rails 4, the ./bin directory contains your app's "binstubs." Binstubs are wrappers around gem executables, like rails or bundle, which ensures a gem executable is run inside the correct environment for your Rails app.
Binstubs can be used in lieu of bundle exec to run a gem's executable inside your app's environment. For example, instead of typing bundle exec rails scaffold products you can type bin/rails scaffold products. Using binstubs is more flexible than bundle exec, because you don't have to cd to the app's root directory and type bundle exec before everything.
By default, bundle, rails, rake, setup, spring binstubs are created automatically for new rails projects. To make a binstub for a gem executable, just type bundle binstubs name_of_gem_executable. You'll find the new binstub in your ./bin directory.
Some suggest putting ./bin in your shell's search $PATH, so that you don't have to type bin/rails and you can just type rails. This is risky because it depends on ./bin coming before the gem executable's path in $PATH; if you happen to forget this ordering and adjust $PATH such that the gem's executable is found before the binstub wrapper, you could easily invoke the gem's executable -- sans the environmental pretext -- without realizing it.
A bin (short for binary) is nothing more than an application. As you have noticed, these files are ruby files, but they do not have the .rb extension and can be run from your shell just as any shell command, without the need to start any ruby interpreter yourself.
So what do theses programs do? I'm pretty sure you know already what rails rake bundle do.
About spring, it's a gem that keeps your app running in the background (hence its need to be run independently from the app). More infos on their github.
I see no reason to edit these files, but that being said, they're ruby files so you can do whatever you want with them. One example of why you may want editing can be found here.
I personally do put some stuffs in the bin folder. Scripts to connect to remote servers, or ruby scripts I need but that I don't want to run as rake tasks since they're more general than my application.
I know that if application uses bundler, I can easily find all the gems installed by looking at the Gemfile.
Say, I am looking at the Rails 3 application that doesn't use bundler, how do I know what gems it uses?
Thanks
If it's not using Bundler, I don't know of a definitive way to identify every gem being used. You could search the entire app tree for require statements to start with, but that's not going to show most of them. Gems also require other gems internally, and will install their own dependencies, but those gems won't be referenced directly from your app's require statements.
If the app works and the tests pass (meaning you've at least got all the required gems installed), you could approach the problem by creating a Gemfile, listing the gems you know are needed, and then running your tests (or the app itself) via bundle exec, which will ensure that only the gems listed in the Gemfile are visible. Then you'll get failures related to missing gems, and can add them to the Gemfile until it all works. Once it's working via bundle exec, you'll know that you've captured all the requirements there.
If you're using RVM, you'll probably find it helpful to create a gemset for your app, along with a .rvmrc file in the app root, to take advantage of RVM's automatic gemset switching and Bundler integration. It'll make it easier to maintain the gem state going forward.
In any case, running gem list with the app in a working state will show you all the gems that it might be using, but without being scoped to a gemset or wrapped in bundle exec, you'll also see gems that were installed for other reasons that potentially have nothing to do with your app's dependencies.