So I had a couple rails apps with cucumber features on my Macbook Pro when I did the in-place upgrade for Lion.
So now I have XCode reinstalled, updated all my gems, and when I start the rails server everything seems to be good to go. But if I run cucumber features I get the following:
You have already activated rack 1.3.2, but your Gemfile requires rack 1.2.3.
Consider using bundle exec. (Gem::LoadError)
So I deleted Gemfile.lock to get rid of the old gem list, bumped the rails version on Gemfile to the new one, and ran bundle install again, and it did it's thing. No errors, but the cucumber features will not run for the life of me.
Your environment is fine and you always should user bundle exec if you want to execute a gem binary, in this case it will always start executable of version that is declared in Gemfile, in other case without bundle exec it will start binary from version installed in your system, sometimes they could match (but it is only coincidence).
Add something like that to your profile to avoid long command call:
alias bec='bundle exec cucumber -r features'
Related
I've been scratching my head with this one for close to 2 weeks. I have an Ubuntu 14.04 server with rbenv installed running a number of different Rails websites, some of them on older versions of Rails, some of them on the latest version.
I have 2 websites in particular that both require a different version of puma_worker_killer, 1 requires 0.1.0 and the other 0.1.1. Both these websites use Ruby 2.5.3.
When I start the server with RAILS_ENV=dev3 bundle exec pumactl -F ./config/puma.rb start I get the following error in the logs and the website hangs:
You have already activated puma_worker_killer 0.1.1, but your Gemfile requires puma_worker_killer 0.1.0. Prepending `bundle exec` to your command may solve this. (Gem::LoadError)
At first I thought it may've been an issue with rbenv as I had the gems installed in ~/.gem instead of in ~/.rbenv so I've nuked all rubies in ~/.gem and installed them freshly into the correct rbenv folder with bundle install and I still get this same issue.
Now at this point I want to clarify that I've done extensive research on this subject online and I know that I can do many things to solve this.
I know I can just change the version and bundle update puma_worker_killer.
I also know I can remove the latest version by doing gem uninstall puma_worker_killer and choosing 0.1.1 but this would mean the dependencies on the other website wouldn't be met.
I've done some digging into the source code of bundler and can see that it's caused by the following line of code:
return if activated_spec.version == spec.version
When running in the context of bundler using bundle exec both the activated_spec and spec match, meaning that the following code in that method (check_for_activated_spec!) doesn't run. For some reason, when running the command above to start the server, activated_spec (the activated gem) is the latest version (0.1.1) and not the one listed in the Gemfile (0.1.0), meaning it doesn't return and throws the error above.
I should also mention that there also seems to be the same issue with get_process_mem, which is one of the dependencies of puma_worker_killer. It complains of already activating 0.2.5 but my Gemfile wants 0.2.4:
You have already activated get_process_mem 0.2.5, but your Gemfile requires get_process_mem 0.2.4. Prepending `bundle exec` to your command may solve this. (Gem::LoadError)
It is my understanding of bundler that it should load the version listed in the Gemfile when using bundle exec to counteract this very problem of having multiple versions of the same gem.
I know I could also create a separate gemset (which can be done with rbenv apparently) that has different versions of puma_worker_killer in them and then run rbenv local 2.5.3-pwk0.1.0 or rbenv local 2.5.3-pwk0.1.1 depending on the version I want, inside the project, but that seems overkill for what I want to achieve.
At this rate I'm tempted to just update all websites with the latest version of both puma_worker_killer and get_process_mem and then lock them in and remove all older versions on the server, but I don't think I should have to do that.
Does anyone know what's happening here or whether I'm doing something glaringly wrong?
Below is the piece of code I use to use puma_worker_killer in my puma config.
before_fork do
require 'puma_worker_killer'
PumaWorkerKiller.config do |config|
config.ram = 1024 # mb
config.frequency = 5 # seconds
config.percent_usage = 0.98
config.rolling_restart_frequency = 12 * 3600 # 12 hours in seconds
end
PumaWorkerKiller.start
end
What is happening here is basically you have several versions of the gem in your system.
Most of the time it did not cause issues because bundle exec will dynamically load required versions for your application.
In some cases gems will have binary files included. It such case bundle exec will not help because you can have only one version linked in one moment.
Basically, if you want to call the binary by alias you have to use separate gemset for each application.
If you want to keep all the gems in one place you can call binary files directly.
In your case it will be:
RAILS_ENV=dev3 bundle exec pumactl _0.1.0_ -F ./config/puma.rb
The _<version>_ construction allows you to specify version of the binary file you want to run.
You can create your custom binary as well, like fake_pumactl inside the project which will check the Gemfile.lock and automatically proxy your call to the library and specify version automatically for you. Another way is to parse gem version by shell script and put this script instead of _<version>_ in your call.
Here is the brief example
$ gem install puma
Fetching puma-4.3.3.gem
$ gem install puma -v 4.3.0
Fetching puma-4.3.0.gem
$ pumactl -v
4.3.3
$ pumactl _4.3.0_ -v
4.3.0
$ ruby -v
ruby 2.6.3p62
$ export puma_version=_4.3.0_
$ pumactl ${puma_version} -v
4.3.0
puma_version variable can be defined from result of a bash command which will extract the gem version from Gemfile.lock.
I have staging and productions servers through AWS. After a certain point of time(I think it was after I upgraded ruby version to 2.1), my staging/production servers couldn't find rails so I had to ssh in and redownload Rails and Ruby, but now when I run "rails -v" it gives me 2.3.14, but when I run "bundle exec rails -v" I get the proper 3.2.16.
I'm guessing this is because of paths, but not entirely sure how to solve this. Some of the answers I found suggested changing the .bashrc and changing the $PATH variable, but wasn't exactly sure what to change it to.
This is my .bashrc:
#PATH=$PATH:$HOME/.rvm/bin # how it was before
PATH = $PATH:$HOME/.rvm/gems/ruby-2.1.0/bin #edited this just now to see if it works. it didnt..
bundle exec rails will use the rails version defined in your Gemfile. On the other hand, a simple rails will run the latest version available on your computer.
What probably happened is this:
you had a rails version from rvm that was the same as the one used in your Gemfile (3.2.16), so you were not noticing any difference. After upgrading ruby, you have to reinstall all gems you did install on your previous version. Otherwise it will fallback to the latest available, which can be the system version (ie. not from rvm). This may explain why you have such an outdated one.
Note that a proper bundle install will install all the gems required in your Gemfile and then will do the job for you.
I'm following this recipe:
https://github.com/gitlabhq/gitlab-recipes/blob/master/install/centos/README.md
Step Initialize Database and Activate Advanced Features:
bundle exec rake gitlab:setup RAILS_ENV=production
I can't pass that step, tried several ways of getting to work, create a specific gemset, used the default, and I'm still getting the error as it couldn't find any gem, first it asks for Rake, but it's installed. Tried (without bundle exec) rake gitlab:setup RAILS_ENV=production and he asked for another gem, installed the one asked and it asks for another. Tried bundle install, which give me some curious thing, every time I tried it installed all the gems, it didn't show "using gem X (x.x.x)" was "installing gem X (x.x.x)" always.
I'm hoping for someone who passed for such problem installing Gitlab on production and could give me some light how to solve this.
I'm using Ruby 2.0.0. RVM. Cent OS 6.2. Gitlabhq 6-1 branch.
I'm trying to start my rails server with "rails server". I am getting the following error.
Could not find rake-0.9.2.2 in any of the sources
Run bundle install to install missing gems.
when I use gems, it say it is updated. Am I missing some type of path?
I am using MAC OSX Lion with the newest version of Ruby, Rake, Rails.
Run bundle install to make sure all the bundled gems are installed and available to the project.
Then try starting the server with bundle exec rails server - it's possible you've got the rake gem installed at the system level at a slightly different version level than what rails want. If you run rails via bundle exec, it'll set everything up for you
I originally posted the question: What does this Cucumber error message mean?
Following the suggestion of uninstalling builder and running bundle worked, for a while. Now I am getting a similar error, but this time on rack.
When I run cucumber features I get the following (previously cucumber has worked):
can't activate rack (~> 1.2.1,
runtime) for ["actionpack-3.0.7",
"railties-3.0.7"], already activated
rack-1.3.0 for ["rack-test-0.6.0",
"cucumber-rails-0.5.0"]
(Gem::LoadError)
Deleting rack just to get cucumber to work doesn't sound like a really good idea to me. How can I fix this problem so it doesn't come back again on another dependency?
I think you could put the exact version numbers for your gems (including Cucumber) in your Gemfile and then run using bundle exec
bundle exec cucumber
This will run the Cucumber version in your Gemfile, which should always keep things working even when you upgrade your system version.
The other option is to use RVM gemsets