This link is great.
However, there is a problem that I am having that I can not figure out. There are gems that I set in my Gemfile that rails seems not to recognize.
When I navigate to my rails application and run these two commands they give me unexpected results.
bundle exec irb
$:
and
bundle exec rails c
$:
gives different result. The former give more paths (which include paths to gems), and the later less. I thought it should be the other way around.
And specifically the bundle exec irb loads all the gems from the my Gemfile. But bundle exec rails c only loads some of the gems from the Gemfile.
How do I get rails to load all my gems from the Gemfile of my rails application?
Related
What does bundle exec rake db:migrate really means? or bundle exec rails s
I understand that bundle handle all the gems we specify in our Gemfile,and rake handle all the things which you can do through scripts but these commands don't get executed without prefixing bundle exec and I couldn't find any documentation about this on internet !!
Bundler - The best way to manage your application's dependencies
Run the command in context of the bundle
$ bundle exec
Exec runs a command, providing it access to the gems in the bundle. While using bundle exec you can require and call the bundled gems as if they were installed into the systemwide RubyGems repository
With:
bundle exec rake db:migrate
In an informal way, it means that your rails environment will
-Install dependencies with bundler
then
-Run your database migrations in your rails app (/yourapp/db/migrate)
Instead of a database operation, you could do any other command line stuff that can be controlled by rake (like building your app, extensions, cleaning some files, etc.)
This can be useful if you want to avoid confusing scenarios where maybe some gems in your setup are outdated, or missing from your environment. It's a good practice because calling rake by itself will not guarantee that you got all your dependencies in check.
Bundler acts to create a somewhat isolated Ruby language programming environment separate from the underlying host system. There are limits to what it can do. For example, you need something like RVM to manage different versions of the Ruby language virtual machine. And of course both Ruby and Bundler itself have to be available outside your project in order to run.
However, within a single project bundle exec will restrict access to gems installed by Bundler into that project. This means that the Rake utility when invoked via bundle exec will be the version of rake installed in your project and not the system-wide version. It also means that `bundle rake db:migrate' will use the correct version of rails installed for your project. This isolates your project from updates done to the Ruby environment on the host and thereby prevents compatibility issues from arising.
You can get around the verbosity by creating aliases in your .bash_profile (assuming you are using OSX or Linux/unix) for bundle exec, bundle exec rake and bundle exec rails. I use bexec, brake and brails.
I really like that Spring is included in the Rails standard Gemfile now. I have a new project I started from scratch where I can just type:
rake <my rake task>
and it's run under Spring so that the whole environment doesn't have to load again.
However, I recently upgraded a project from v3.2 to v4.2.3, and I get an error. It only works if I do:
bundle exec rake
How can I get this upgraded project to run under spring again?
It seems you have system wide and application specific gem sets that conflict each other. Simply remove system wide gems and use Bundler special feature. Bundler binstubs helps to avoid prepend bundle exec every time:
gem uninstall rake
bundle install --binstubs
./bin/rake
https://github.com/sstephenson/rbenv/wiki/Understanding-binstubs
Assuming the binstubs for a project are in the local bin/ directory,
you can even go a step further to add the directory to shell $PATH so
that rspec can be invoked without the bin/ prefix:
export PATH="./bin:$PATH"
rake
I am relatively new to Rails, and using version 3.x.I have just found out about bundle binstubs gem command which creates executable wrappers in /bin dir.Is there any benefit running commands from bin/ if there is already rake task for that.For example, I would use rake spec:models , which I prefer over bin/rspec spec/models/.
Yes.
As an example, when you install gems locally within your rails app using Gemfile and bundle install, you normally need to do a bundle exec before running tasks, so as to resolve ruby gems dependecies from the app directory, not from installed otherwise (using gem install <gemname>).
With binstubs, you don't need to do that.
Example: bundle exec rake RAILS_ENV=production onetime:generate_report without binstubs and
rake RAILS_ENV=production onetime:generate_report with binstubs
I learned Rails using just the rake command like rake db:migrate; however, I read that I should be using the bundle exec rake ... instead of just plain rake. Now I'm confused about which to use.
Should I be using bundle exec rake instead of just plain rake or is it just a preference thing? Any insight would be much appreciated! Thanks!
bundle exec executes a command in the context of your bundle.
That means it uses the gems specified in your Gemfile. Much of the time, running bundle exec rake foo has the same results as if you just ran rake foo, especially if you have the same gems installed systemwide as in your Gemfile. However, some applications may specify different versions of gems than the ones you have installed systemwide, and may want those exact gems and versions to be able to run correctly. If you just run without bundle exec, you may get some weird errors.
Using bundle exec guarantees that the program is run with the environment specified in the gemfile, which hopefully means it is the environment that the creators of the program want it to be run in, which hopefully means it should run correctly no matter what weird setup you have on your computer.
It basically standardizes the environment under which the program is run. This helps avoid version hell and makes life much easier.
See http://bundler.io/v1.3/man/bundle-exec.1.html for more info.
$ bundle exec rake db:migrate
Uses the version of rake specified in the Gemfile to execute the rake task db:migrate.
But there is no rake gem specified in the Gemfile!
Yes, but a rake gem was installed as a dependency of some other gem--look in Gemfile.lock. So the rule must be: Uses the version of rake specified in Gemfile.lock.
But Gemfile.lock doesn't specify a specific version--it specifies a version greater than x.y!
Then the rule must be: Uses the version of rake that was installed in the current gemset.
$ rake db:migrate
Normally, when you issue a command on the command line, e.g. rake, your system searches for the command in the list of directories specified in your PATH environment variable. The first directory that contains the command is the version of the command that is used. To see which directory that is, you can do:
$ which rake
So if you execute,
$ rake db:migrate
that may use a different rake gem than the one you installed with bundle install. But, even if your system finds the same rake version as bundle exec, any gems required by the rake source code will be searched for in places outside your project's gemset. Therefore, there are many ways that just:
$ rake db:migrate
can screw things up.
According to the Ruby on Rails Tutorial Book(free online), section 3.6, if you are using rvm 1.11.x+ then you do not need to preface commands with bundle exec.
running any exacutable without bundle exec will have Rubygems fetching the latest version of the gem installed in your system.
By adding the bundle exec prefix instead will have the executable running in the context of your Gemfile.lock, which means that will be run using the version defined in the gem file.
Having some issues deploying this. I've tried to deploy it twice now. Here's what I've done so far....
Installed the gems and versions required on the install page:
gem install -v=2.3.5 rails
gem install -v=1.0.1 rack
gem install -v=0.8.7 rake
gem install -v=0.4.2 i18n
Downloaded the package:
git clone git://github.com/chiliproject/chiliproject.git
cd chiliproject
git checkout stable
Had to find and set bundle since it wasn't in my path:
BUNDLE="/usr/lib/ruby/gems/1.8/bin/bundle"
Put my database info into database.yml:
And then started the bundle stuff:
$BUNDLE install --without=postgres rmagick
$BUNDLE exec rake generate_session_store
The last command got the error:
rake aborted!
can't activate rails (= 2.3.5, runtime), already activated rails-2.3.12. Make sure all dependencies are added to Gemfile.
So I changed 2.3.12 to 2.3.5 in the Gemfile and carried on:
RAIL_ENV=production $BUNDLE exec rake db:migrate
Then I got an error on this command too:
** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
rake aborted!
undefined method `autoload_paths' for #<Rails::Configuration:0x68a68dbb82c0>
/home/USERNAME/DOMAIN/public/config/environment.rb:44
I tried commenting out line 44 there, but then it threw another error undefined methodconvert_to_without_fallback_on_iso_8859_1' for class Class' so I didn't want to play around with it further. Note this only happened the second time I tried to deploy it. The first time I tried db:migrate succeeded (and I checked there was not data already in the DB).
*So for the second try I am stuck here :-( *
But this is what happened the first time after db:migrate succeded....
RAILS_ENV=production $BUNDLE exec rake redmine:load_default_data
With the last command however it failed saying permission denied for mysql 'user'#'173.236.128.0/255.255.128.0' and I was like WTF is it trying to connect to a network as if it were a host?
So I moved on, copied my configuration file and environment files in. Changed/added these lines:
# Uncomment below to force Rails into production mode when
# you don't control web/app server and can't set it the proper way
ENV['RAILS_ENV'] ||= 'production'
# Specifies gem version of Rails to use when vendor/rails is not present
RAILS_GEM_VERSION = '2.3.5'# unless defined? RAILS_GEM_VERSION
if ENV['RAILS_ENV'] == 'production' # don't bother on dev
ENV['GEM_PATH'] = '/home/USERNAME/.gems' + ':/usr/lib/ruby/gems/1.8'
end
Then made this stuff writable and restarted Passenger:
chmod -R 777 files log tmp public/plugin_assets/
touch tmp/restart.txt
Sorry for the wall of text, is anybody able to shine some light on something I've done wrong?
Thanks in advance.
EDIT: So this is all wrong, here's how I got it working
rm ~/.gem*
gem install bundler
PATH=$PATH:/usr/lib/ruby/gems/1.8/bin
cd ~
git clone git://github.com/chiliproject/chiliproject.git
cd chiliproject
git checkout stable
cp * ../example.com/ -R
cd ../example.com
# Make sure database is working
bundle install --without postgres rmagick test
bundle exec rake generate_session_store
RAILS_ENV=production bundle exec rake db:migrate
# No output is no good, check database.yml
RAILS_ENV=production bundle exec rake redmine:load_default_data
Or see this: https://gist.github.com/1127306
The current ChiliProject stable releases (2.x) require the use of bundler. Thus the answer by Slotos is incorrect here. gen install doesn't work anymore, we NEED bundler.
Also, we require Rails 2.3.12 now. You won't get any working results if you arbitrarily edit files. On certain platforms, you need to adapt the Gemfile (e.g. when using Ruby 1.8.6 or for certain versions of ImageMagick). For the currently suggested setup using Ruby 1.8.7 or REE, you don't need to adapt anything though.
For installing the dependencies of the currently stable ChiliProject 2.x releases, you basically need to do the following:
At first you need to make sure that the directory where gem binaries re installed to is in your $PATH. This can be temporarily be achieved by running this (in your case)
export PATH=/usr/lib/ruby/gems/1.8/bin:$PATH
Then you need to install the bundler gem and instruct it to install all dependencies
gem install bundler
bundle install --without rmagick postgres test # in your case
What is really strange in your case is that rake seems to try to enable Rails 2.3.5. It should not do that (and doesn't unless you have changed certain files). I strongly recommend to start with a new clean source tree and don't change any arbitrary files.
Don't mix up gem install commands with bundler package management. You will get unexpected results from doing so.
If you really want to use bundler - add all the gems you want into a Gemfile.
Otherwise just omit it.
Quick search for "bundler chiliproject" lead me to chiliproject-gemfile. Apparently it have been merged into unstable already.