← Back to Upcase

Issue with Rspec after switching from RVM to Rbenv

Hi, recently I uninstalled RVM from my system in favor of Rbenv.

Apperently uninstalled all my gems like Rails and Rspec

So I reïnstalled them. However now I’m having an issue with Rspec when I run the test in my Rails project:

/Users/acandael/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/bundler-1.6.5/lib/bundler/runtime.rb:34:in `block in setup': You have already activated rspec-core 3.0.3, but your Gemfile requires rspec-core 2.14.8. Prepending `bundle exec` to your command may solve this. (Gem::LoadError)

I can run my test, but I have to prepend it with ‘bundle exec’:

bundle exec rspec

Is there a way to solve this issue, so I can run my test again by simply typing:

rspec

thanks for your help,

Anthony

Hi @acandael_acanda, I usually just use bundle exec aliased to be. You can however use rbenv-gemsets so that you use gems on per project basis. There are probably other ways to achieve this though.

Hi pedro, thanks for the information. I think I’ll just type bundle exec. How did you alias the command to shorten it to ‘be’ ?

greetings,

Anthony

I actually got that by using thoughtbot’s dotfiles.

It is just a definition in ~/.aliases: alias be="bundle exec"

You might also want to check that you have a binstub for rspec and that when you type which rspec from your app’s root that you get the binstub (meaning it’s in the proper location in your path). You shouldn’t have to be using bundle exec very often with a modern Rails app for things like rspec and rake with proper binstubs.

1 Like

Thanks Pedro

just created the ~/.aliases file and add the alias, and it works

greetings,

Anthony

Hi Geoff,

How can I create this ‘binstub’ ?

When I type the command: ‘which rspec’ in my Rails app root, I get:

/Users/acandael/.rbenv/shims/rspec

greetings,

Anthony

@acandael_acanda I do the following:

In ~/.zshenv (~/.bashrc if on bash) on my machine, one-time setup:

export PATH=".git/safe/../../bin:$PATH"

For each Ruby app I work in, one-time setup per app to safely load binstubs:

mkdir -p .git/safe

To create the binstubs, one-time setup per app:

bundle binstubs --all

Or, if you want just the RSpec binstubs:

bundle binstub rspec-core

You can check that binstub into version control so your teammates also have it.

Now, I can run the command without bundle exec:

rspec
3 Likes

No problem, glad to help :slight_smile:

Hi Dan, thanks for the instructions. Do I need to literaly add:

export PATH=".git/safe/../../bin:$PATH"

to my ~/.bashrc file, or are the dots (…) placeholders for something else?

greetings,

Anthony

@acandael_acanda, the commands @croaky pasted should be used exactly as they are, there’s nothing to replace.

The dots tell your shell that for any original folder that has a subfolder with .git/safe in it, that the bin folder located in the original folder (two folders above safe, which is back where you started) should be in your path.

The reason this approach works is that it’s not possible to put things into the .git folder of a repository that get stored as repository contents, so if you were to download a git repository from someone else, that repo could only be declared as “trusted” by you adding safe to the .git folder.

BTW, it’s important that safe is a folder and not a file, or else the entry won’t be valid in your path and your shell will ignore it.

1 Like

Hi Dan,

Thanks a lot! I just added the Rspec binstub and it works!

greetings,

Anthony

how odd, all of a sudden, after all was working fine, I get the same error again when trying to do run my testsuite with ‘rspec’:

/Users/acandael/.rbenv/versions/2.1.2/lib/ruby/gems/2.1.0/gems/bundler-1.6.5/lib/bundler/runtime.rb:34:in `block in setup': You have already activated rspec-core 3.0.3, but your Gemfile requires rspec-core 2.14.8. Prepending `bundle exec` to your command may solve this. (Gem::LoadError

to fix this I ran this command again:

bundle binstub rspec-core

but then I get the message

Skipped autospec and rspec since they already exist.

Anthony

I would try two things at this point:

  1. Make sure that which rspec is executing the binstub (verify the returned path).
  2. Delete the rspec binstub and then regenerate it the same way you did before with bundler.

If #1 is OK and you do #2, that should fix your version conflicts.

Hi Geoff,

when I type the command

which rspec

I get:

/Users/acandael/.rbenv/shims/rspec

I that the rspec binstub I need to delete, or is the rspec binstub located in my Rails project folder?

greetings,

Anthony

That output means that your binstub is not coming first in the path. What’s the output of echo $PATH when you type that in the shell?

the outpu of $echo PATH is:

/Users/acandael/.rbenv/shims:/usr/local/mysql/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/opt/sm/bin:/opt/sm/pkg/active/bin:/opt/sm/pkg/active/sbin

OK, it looks like you need to go back and try to implement the edits to .zshrc or .zshrc.local that @croaky described above. The two things you need to fix are:

  1. Check that no further path editing statements prevent .git/safe/../../bin:$PATH from ending up at the front of your path. Rbenv loading will modify the path (by inserting its shims in the front), so do that before you try to add the git safe entry to the path.
  2. Make sure that you have a safe folder in your app’s .git folder. It has to be a folder, it can’t be a file.

If those two items are corrected, and you have an rspec binstub in your binstubs folder, you should get the binstub as the result of which rspec.

1 Like

Hi Geoff thanks,

I don’t know how to check for editing statements preventing .git/safe/…/…/bin:$PATH from ending up at the front of my path.

The only thing I did was switch the two statements in my .bashrc file:

export PATH="/usr/local/heroku/bin:$PATH"
export PATH=".git/safe/../../bin:$PATH"

to:

export PATH=".git/safe/../../bin:$PATH"
export PATH="/usr/local/heroku/bin:$PATH"

then I ran the command: bundle binstub rspec-core --force

again, and know I’m able again to run my tests again with:

rspec

instead of

bundle exec rspec

thanks,

Anthony

Looks like you got it.