I'm running a crontab that executes a rake task. I'm getting the following error (with MAILTO from crontab):
rake aborted!
no such file to load -- bundler
/Users/Mendel/Sites/misnooit/Rakefile:4
(See full trace by running task with --trace)
I'm using rvm with:
ruby: ruby 1.9.1p378
rails: Rails 3.0.0.beta
$GEM_HOME: /Users/Mendel/.rvm/gems/ruby-1.9.1-p378
bundler: bundler (0.9.11)
The error is pretty self explanatory but I'm not able to fix it.. Is there someone with more knowledge about this matter? Thanks in advance.
I just experienced this. Problem for me was that the instances of rake and ruby I use were built locally, and installed to /usr/local/bin. There are other versions in /usr/bin (must check what I installed using apt-get in the past..).
So, in my crontab file I set the path using
PATH=/usr/local/bin:/usr/bin:/bin
(I was seeing it as PATH=/usr/bin:/bin in the failed crontab emails)
and it works.
Just guessing: is Ruby 1.9.1p378 your default Ruby?
I think it's not so you can just execute rvm --defaults "ruby-1.9.1-p378"
If this doesn't help, are you sure bundler has been installed when ruby 1.9 was used?
Also, in your test/production environment, you may want to run you cron with another user than yourself. So I suggest you install rvm as "root", and set up (still as root) a default RVM that will be the default for all the system users.
And of course, you can override this per user.
I've had good experience using http://github.com/javan/whenever
It uses a Ruby DSL to manage cron tasks and it handles setting all the environment magic.
every 3.hours do
runner "MyModel.some_process"
rake "my:rake:task"
end
have your run the command with --trace asserted to ensure there isn't something obvious in the rake command, but what you could do is chain the crontab commands
rvm 1.9.1;rake do_whatever_task
That way it will load the ruby environment every time prior to running rake.
I had a similar issue this weekend, I found that my Rake Gem was updated to 0.90 you need rake 0.8.7. This solved the issue on my end.
Related
I am trying to follow the Redmine guide here.
I am running into the same problem this previous post, but the solution didn't solve it for me.
Steps that I have done so far:
Ruby
I have downloaded/installed the Ruby from http://rubyinstaller.org and verified that Rails was installed.
rails -v
Rails 5.1.3
ruby -v
ruby 2.3.3p222
MySQL
Visual Studio 2019 redistributable installed.
Ran the MySql installer msi
Selected the Developer (Defaults)
Took all the defaults for the rest of the wizard (I did set root password and added a user)
*I think I had to do all this first before starting the Installation procedures.
Redmine
Completed step 1-4 with the MySQL settings
Step 5
Running the command:
bundle exec rake generate_secret_token
Could not locate Gemfile or .bundle/ directory
I have verified that rake is installed
rake -V
rake, version 13.0.1
gem list rake
(rake 13.0.1)
Using the stackoverflow post from above, I did update the version of rake I had installed, but that didn't solve the issue. I am new to gem/bundle type of installs, so I may be missing something that is quite obvious.
Do I need to be a specific directory when running these commands?
Any direction for me would be good. I am trying to run this on a Windows Server if that makes any difference.
Redmine is a Rails app. You must download the app, extract it, then change into that directory before running your rake task. The process for this is defined in step 1:
Get the Redmine source code by either downloading a packaged release or checking out the code repository.
See the download page for details.
Afterwards, you can run bundle exec rake generate_secret_token because that is a Rake task defined by lib/tasks/initializers.rake. Rake tasks in Rails are typically defined within the lib/tasks directory and you can see multiple examples there.
If you attempt to run rake something then Rake is going to look for a Rakefile where this task is defined. Since you're currently just in your Ruby bin/ directory there are no defined rake tasks so you get the errors that you see.
I recently set up a production server for a Rails 3 app.
On the initial deploy everything worked fine. On a subsequent deploy, new gems that were added to the project are not being found. I am getting uninitialized constant and undefined method errors when I reference classes and methods from the newly added gems, respectively.
When I originally set things up I was using a gemset with RVM, but have tried to simplify things by removing the gemset and only using RVM to manage rubies.
When I run bundle list every thing is there. All of the gem are in <app_root>/shared/bundle/ruby/1.9.1/gems/
It seems like maybe it's loading the gems from some other location, like the original gemset, but I have deleted it.
Some other details, I am using Capistrano, of course, Unicorn, my GEM_HOME=/home/deployer/.rvm/gems/ruby-1.9.3-p286
Let me know if there is any other info I can provide.
Thanks.
if you use bundle install --deployment then you also have to prefix commands with bundle exec when you execute the command, like:
bundle exec rake db:migrate
If you use bundler/capistrano integration then it does it for you in capistano but in console you need to use bundle exec manually.
RVM was helping you to avoid it with rubygems-bundler gem - but you changed gemset so the generated wrappers are no more available. You would have to clean <app_root>/shared/bundle/ruby/1.9.1/gems/ and run bundle install again to regenerate the wrappers to avoid typing bundle exec again.
I have similar problems. It turns out Capistrano isn't properly restarting unicorn. SSHing into the server and stopping then starting unicorn did the job. Now to find a fix for Capistrano's shenanigans...
I thought I understood how Bundler works with gems, but after something that recently happened, I am not sure I have it right.
I am developing an Rails application. To start off (and just so I would get familiar with the Rails environment which I haven't worked in before), I did not use an IDE. But, because I'm missing out on some of the advantages of an IDE, I just started using RubyMine. As part of the RubyMine setup, it asked to update all my gems for my existing project.
After that, I could not run "rake [anything]". Every time I did, I received an error of:
You have already activated rake 0.9.3.beta.1, but your Gemfile
requires rake 0.9.2.2. Using bundle exec may solve this.
I was okay updating to the next version of rake - that wasn't a problem - but I don't understand what happened in the first place. What happened that I "activated" a newer version of rake. Ultimately, I ended up solving the problem by putting
gem 'rake', '0.9.3.beta.1'
in my Gemfile and running
bundle update rake
But, I'm still not sure what happened here. If I was using 9.2.2 before, why did it all of a sudden blow up like that and how can I prevent that in the future?
If you are using Rubymine, you should configure it to run rake tasks with bundle exec.
Go to:
Run -> Edit Configurations -> Defaults -> Rake -> Bundler tab and check "Run the script in context of the bundle (bundle exec)"
Delete all tasks already created and the default will apply the next time you create them again. You can also configure individually each task created.
You should really consider installing and using RVM or Rbenv to manage your ruby versions and gemsets. If you go the Rbenv way, the rbenv-gemset plugin can be used to manage gemsets similar to how RVM natively does.
You have already activated rake 0.9.3.beta.1, but your Gemfile requires rake 0.9.2.2. Using bundle exec may solve this.
At some point between your last bundle execution and installing/configuring/running RubyMine you must have installed rake 0.9.3.beta.1. Because you're not managing your gems through gemsets like RVM or Rbenv will do for you, the default version of Rake became 0.9.3.beta.1 instead of the version installed by bundler, 0.9.2.2.
The above error suggests your Gemfile had something like
gem 'rake', '0.9.2.2'
which does not allow the version of rake being used to be anything but 0.9.2.2.
If you do in fact have 0.9.2.2 on your system in addition to the 0.9.3.beta.1 and your Gemfile is configured for 0.9.2.2, instead of running
rake some:task
you can run
bundle exec rake some:task
and bundler will run some:task through the 0.9.2.2 version of rake. Running tasks related to gems found in a Gemfile through bundleer with bundle exec ... is considered good practice regardless of using RVM or Rbenv.
You can read about bundle exec here.
Alright, well I'm trying to fix this problem again. I followed this fix to eliminate the error by reverting to version 0.8.7, which worked the first time. However, now I'm trying to use cucumber and I'm getting it all again.
I tried it again by running gem uninstall rake -v=0.9.2.2 which lists all the gem dependencies. Successfully uninstalled. Then I ran bundle update rake. Using rake (0.8.7). Cool. rake -V. rake, version 0.9.2.2. wat. Same problems return. What am I missing? I thought 9.2 was supposed to fix this bug anyway?
I think this fix is obsolete. Rake 0.9.0 got fixed, and 0.9.2.2 is certainly working. You want to uninstall and completely eradicate rake 0.8.x. Try something like:
gem list -d rake
The -d switch will show the installation directories. If you're using RVM, there may be multiple search paths that get hit, running rvm info will tell you the search path and preference ordering. Depending on the system you're on, your OS may also ship with an old rake version. Try uninstalling everything other than the local gemset (if using RVM) or the latest rake (if not using RVM).
The problem with the rake gem uninstall sounds like you have Rake in your default gemset, check ~/.rvm/gemsets/global.gems It will no doubt have rake in it
What does bundle exec rake db:migrate mean? Or just bundle exec rake <command> in general?
I understand that bundle takes care of maintaining things in the Gemfile. I know what the word "exec" means. I understand that rake maintains all the different scripty things you can do, and I know that db:migrate is one of those. I just don't know what all these words are doing together. Why should bundle be used to execute rake to execute a database migrate?
bundle exec is a Bundler command to execute a script in the context of the current bundle (the one from your directory's Gemfile). rake db:migrate is the script where db is the namespace and migrate is the task name defined.
So bundle exec rake db:migrate executes the rake script with the command db:migrate in the context of the current bundle.
As to the "why?" I'll quote from the bundler page:
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.
You're running bundle exec on a program. The program's creators wrote it when certain versions of gems were available. The program Gemfile specifies the versions of the gems the creators decided to use. That is, the script was made to run correctly against these gem versions.
Your system-wide Gemfile may differ from this Gemfile. You may have newer or older gems with which this script doesn't play nice. This difference in versions can give you weird errors.
bundle exec helps you avoid these errors. It executes the script using the gems specified in the script's Gemfile rather than the systemwide Gemfile. It executes the certain gem versions with the magic of shell aliases.
See more on the man page.
Here's an example Gemfile:
source 'http://rubygems.org'
gem 'rails', '2.8.3'
Here, bundle exec would execute the script using rails version 2.8.3 and not some other version you may have installed system-wide.
This comes up a lot when your gemfile.lock has different versions of the gems installed on your machine. You may get a warning after running rake (or rspec or others) such as:
You have already activated rake 10.3.1, but your Gemfile requires rake 10.1.0. Prepending "bundle exec" to your command may solve this.
Prepending bundle exec tells the bundler to execute this command regardless of the version differential. There isn't always an issue, however, you might run into problems.
Fortunately, there is a gem that solves this: rubygems-bundler.
$ gem install rubygems-bundler
$ $ gem regenerate_binstubs
Then try your rake, rspec, or whatever again.
It should probably be mentioned, that there are ways to omit bundle exec (they are all stated in chapter 3.6.1 of Michael Hartls Ruby on Rails Tutorial book).
The simplest is to just use a sufficiently up-to-date version of RVM (>= 1.11.x).
If you're restricted to an earlier version of RVM, you can always use this method also mentioned by calasyr:
$ rvm get head && rvm reload
$ chmod +x $rvm_path/hooks/after_cd_bundler
$ bundle install --binstubs=./bundler_stubs
The bundler_stubs directory should then also be added to the .gitignore file.
A third option is to use the rubygems-bundler gem if you're not using RVM:
$ gem install rubygems-bundler
$ gem regenerate_binstubs
When you directly run the rake task or execute any binary file of a gem, there is no guarantee that the command will behave as expected. Because it might happen that you already have the same gem installed on your system which have a version say 1.0 but in your project you have higher version say 2.0. In this case you can not predict which one will be used.
To enforce the desired gem version you take the help of bundle exec command which would execute the binary in context of current bundle. That means when you use bundle exec, bundler checks the gem version configured for the current project and use that to perform the task.
I have also written a post about it which also shows how we can avoid using it using bin stubs.
I have not used bundle exec much, but am setting it up now.
I have had instances where the wrong rake was used and much time wasted tracking down the problem. This helps you avoid that.
Here's how to set up RVM so you can use bundle exec by default within a specific project directory:
https://thoughtbot.com/blog/use-bundlers-binstubs
It means use rake that bundler is aware of and is part of your Gemfile over any rake that bundler is not aware of and run the db:migrate task.