I can not run the task of rake refinery:testing:dummy - localization

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

Related

How come rake needs bundle exec, but rails doesn't?

I appreciate all the answers out there as to what bundle exec does, which is that it runs the following commands in the context of the Gemfile bundle. But why doesn't "rails server" need bundle exec? Seems like it should still apply.
The rails command runs from the executable inside the script folder. If you remove this folder, you can see that rails commands stop working. rake however runs differently.

What is the difference between bin/rake and bundle exec rake

What is the difference between using bin/rake and bundle exec rake.
And which is one preferred style?
bin/rake db:migrate
bundle exec rake db:migrate
bundle exec executes a command in the context of your application.
As each application can have different versions of gem used. Using bundle exec guarantees that you use the correct versions.
I use bundle exec always instead of rake because i have multiple applications running on my system.
Try to use bundle exec rake db:migrate always.
You can learn more about it here Official documentation
bin/rake is a kind of stub for the rake command from bundled Gems. It has exactly the same function as bundle exec rake. See http://bundler.io/v1.14/man/bundle-install.1.html and search for binstubs for more about stub. And also note that bin/rake and bin/rails are stubs generated by Rails, which are different in code from the stubs generated by bundler. However, they all serve the same purpose and have the same function.
You have 3 options on a typical system:
bin/rake db:migrate
rake db:migrate
bundle exec db:migrate
The first option is simply calling the path to the rake program, whose launcher can be found in the hidden /bin folder. This launcher is usually just a symlink to the program's content found in your /.rvm directory. You can find its original location by executing $ which rake, which will give you something like /home/ubuntu/.rvm/gems/ruby-2.2.3-p481#devonzuegel/bin/rake.
By default, the second option is essentially the same as the first on most systems. It's what is called an alias, which is basically just a shorthand command for some other program. This is defined somewhere in your shell settings as something like alias rake='/bin/rake'. It's possible that this alias is pointed to a different program on your machine though, so check that before taking my word for it.
When you use bundle exec you're telling bundler to ensure that only the gems and their specified versions from your Gemfile.lock are loaded. This will only work if you're in a directory that contains a Gemfile.lock or whose parent/grandparent directory contains one.

Missing gems & db:migrate Issues

I'm trying to work through this tutorial by Andrew Perkins. When I get to rake db:migrate I get this error and similar subsequent errors every time I install the missing gems.
Could not find rake-0.9.2.2 in any of the sources
Run bundle install to install missing gems.
I've run the bundle install but not sure I've installed properly or with all the right dependencies. I'm pretty new to Rails so don't have a great idea as to where I'm going wrong so any examples of proper installation would be very helpful.
Try
bundle exec rake db:migrate
this ensures that the rake command run is the one specified in your project's Gemfile. You can read more about bundle exec in the docs.

Issue with custom rails engine db:migrate rake task

In rails 3.1 you can use the awesome rake task to copy in migrations as seen below from your engine.
rake my_engine:install:migrations
This normally works perfectly if i direct my Gemfile to the git repository or via :path.
However, if i just use the ruby gem directly
gem 'spud_admin'
my rake task disappears
Any ideas why this rake task disappears?
Well, I had a similar problem and managed to solve it thanks to jipiboily's comment. I have an engine called 'myEngine2' so I tried to call it like that:
rake myEngine2:install:migrations
but this failed. I than typed
bundle exec rake -T
there was a line:
rake my_engine2_engine:install:migrations # Copy migrations from
my_engine2_engine to application
I gave it a shot and it worked. Maybe it's the same problem in your case?
Issue was resolved. It had something to do with how jeweler had structured the gem environment. Switching to bundler and using rails plugin new seems to have resolved the issue.

Use bundle exec rake or just rake?

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.

Resources