I'm going through Mhartl's tutorial and I'm sporadically getting this error when I run tests in the sublime text 2 console. If I use bundle exec rspec/rspec in the the terminal it works fine, but it's not the case when call shortcut commands in sublime text to run tests. I don't know if it makes a difference but I'm also running guard
Users/User/.rvm/gems/ruby-2.0.0-p247#global/gems/bundler-1.3.5/lib/bundler/runtime.rb:33:in `block in setup': You have already activated rspec-core 2.14.5, but your Gemfile requires rspec-core 2.13.1. Using bundle exec may solve this. (Gem::LoadError)
I tried searching stack overflow for solutions and tried bundle exec rake db:migrate(I normally don't specify bundle exec) as well as bundle exec rake test:prepare. Neither of which work.
I'd appreciate not only an answer to the problem but perhaps a more in-depth answer of when to use rake db:migrate and rake test:prepare. I know their main uses, but there are perhaps some less obvious times where i would need to run it. SPecifically, for this problem I would have thought rake test:prepare would be relevant and I'm still not sure what effect rake db:migrate has on the testing suite/rspec part of the application
To answer part of your question, you can delete unused gems through bundle clean, although when I've had multiple versions of gems, I've found that I had to use bundle clean --force which may mean that I had "system gems" coming into play, per https://stackoverflow.com/a/10190608/1008891.
Related
I have a new OS X El Capitan setup with Ruby 2.2 (Macports), Rails 4.2.4 and Bundler for an existing app. Among a lot of other gems, this app uses parallel_tests to make good use of my 8-core machine. rake -T lists all the parallel test and spec tasks fine and in the past I could execute them. But when I do this now, after the upgrade, I just get
$ /opt/local/bin/rake parallel:prepare --trace
rake aborted!
Don't know how to build task 'parallel:prepare'
/opt/local/lib/ruby2.2/2.2.0/rake/task_manager.rb:62:in `[]'
/opt/local/lib/ruby2.2/2.2.0/rake/application.rb:149:in `invoke_task'
What can cause a task to be listed in rake -T, but not be found when I try to execute it?
In this case, the reason was that I had put the gem in question inside a group :test in my Gemfile. Apparently this caused the problem, removing it from the group and making it available globally resolved the problem (after calling bundle again).
I don't know whether this is a generic solution, however.
First time here, I hope do it right.
I'm following the railstutorial 3.2 and I'm in section 5.4, in the paragraph above to listing 5.32.
(In fact, you can just type rake by itself; the default behavior of rake is to
run the test suite.)
I used rake by itselft but I have a error since then. When I run:
"$ bundle exec rake spec" I get this error.
http://pastebin.com/F0wrEkT1
My database.yml is:
http://pastebin.com/tWAgeFTV
My problem is that I don't know why it is asking for production database when I didn't use it yet. And whe I look for the issue I don't find topics about (almost I didn't find it).
Do you have some clues to star looking or to know what is happening?
Thanks a lot.
I'm not sure why it is looking for the production DB but you may want to skip ahead. Just read a little further:
(In fact, you can just type rake by itself; the default behavior of rake is to run the test suite.) The only caveat is that using rake to run the tests for the current sample application will raise an error since it requires the test database to be prepared properly, a step we’ll defer to Section 6.2.1.
It recommends running:
bundle exec rake db:test:prepare
guys! I am a newbie for Ruby on Rails and refinerycms.
Currently, I am study the refinerycms. I want to find all the missing key so as to translate refinerycms. According to the tutorial, I should run the command
bundle exec rake refinery:testing:dummy_app
so as to enable additional useful rake tasks. But when I run this command, it says
rake aborted!
Don't know how to build task 'refinery_testing:dummy_app'
Does any one know the reason?
BTW, I have already added the gem "refinerycms-testing" to Gemfile and installed it already, and I also in the root directory of the project.
I think your problem is that you are not in the good directory.
cd vendor/extension/your_extension_name
bundle exec rake refinery:testing:dummy_app
Hope it helps,
-frbl
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.
I recently set up a Cedar (Rails 3.1) app on Heroku, and to run, for example, a migration, you'd do
heroku run rake db:migrate
I learned that it's good practice to use "bundle exec" before any rake command (as Katz says http://yehudakatz.com/). So, I thought perhaps the following is actually better practice:
heroku run bundle exec rake db:migrate
But to reduce verbosity, is it alright to use the former command, or is the one with bundle exec critical?
On Heroku when the slug is compiled the Gems are installed from into a clean slug as specified in your Gemfile so there's not going to be extraneous Gems floating around the place - there's no need to use bundle exec on Heroku - else I'm sure the Heroku documentation would tell you to do it.
"In some cases, running executables without bundle exec may work, if the executable happens to be installed in your system and does not pull in any gems that conflict with your bundle. However, this is unreliable and is the source of considerable pain. Even if it looks like it works, it may not work in the future or on another machine"
Quoting from bundler's Documentation