I am trying to push a project to Heroku for the first time using git push heroku master. However, I end up getting the following error:
Your bundle only supports platforms ["arm64-darwin-21"] but your local platform
is x86_64-linux. Add the current platform to the lockfile with bundle lock --add-platform x86_64-linux and try again.
Running bundle lock --add-platform x86_64-linux in turn results in the following output:
[17052, #<Thread:0x000000015307bc60 run>, #<NameError: uninitialized constant Gem::Source
... followed by a hundred lines of different paths on my computer.
Does anyone know how to interpret and solve this kind of output?
Thank you very much for your help!
Are you using M1 Mac? if yes then which means the platform is arm64-darwin-20, but the production environment is not.
Try to run below two commands and that will add the two platforms in Gemfile.lock
bundle lock --add-platform ruby
bundle lock --add-platform x86_64-linux
rm -rf Gemfile.lock and run bundle install
It's solved here too. FYI
bundle lock --add-platform ruby
bundle lock --add-platform x86_64-linux
The first answer in the following stack overflow thread did the job for me:
Rails uninitialized constant Bundler (NameError)
#remove project-specific settings
rm -rf .bundle/
# remove project-specific cached gems and repos
rm -rf vendor/cache/
# remove the saved resolve of the Gemfile
rm -rf Gemfile.lock
# rebundle
bundle install
Related
I have set up my aws environment succesfully. However i am having one probelem. In my Gemfile i have the following line:
gem 'activeadmin', :github => 'gregbell/active_admin'
When i do a git aws.push i can see the following error in the aws logs:
/usr/local/share/ruby/gems/2.0/gems/bundler-1.3.5/lib/bundler/source/git.rb:177:in `rescue in load_spec_files': git://github.com/gregbell/active_admin.git (at master) is not checked out. Please run `bundle install` (Bundler::GitError)
I was able to fix that problem by creating this file: .ebextensions/ruby.config
option_settings:
- option_name: BUNDLE_DISABLE_SHARED_GEMS
value: "1"
- option_name: BUNDLE_PATH
value: "vendor/bundle"
packages:
yum:
git: []
This packages everything into vendor/bundle and my app starts correctyl.
However I have two problems with this approach:
It takes very long to deploy because it needs to install all gems every time
I am not longer able to execute commands when I ssh into the EC2 instance. For example I have to start an rpush deamon. Locally this works with bundle exec rpush development but on EC2 this results in:
bundle exec rpush
/usr/local/share/ruby/gems/2.0/gems/bundler-1.3.5/lib/bundler.rb:284: warning: Insecure world writable dir /var/app/current/vendor/bundle/bin in PATH, mode 040777
git://github.com/gregbell/active_admin.git (at master) is not checked out. Please run bundle install
Is there an other way for installing the gems correctly and at the same time using the system gems? Or if that is not possible, how can I start rpush when the gems are bundled?
Update your Gemfile.lock (bundle install&& bundle update) in your local env. and push a commit with Gemfile and Gemfile.lock. Deploy to AWS again.
Can you check if using gem 'activeadmin', 'git://github.com:gregbell/active_admin' in your Gemfile works for you?
You can also get faster deployments utilizing vendor/cache by following the instructions given here:
http://blogs.aws.amazon.com/application-management/post/Tx2XVRWSS4E971S/Locally-Packaging-Gem-Dependencies-for-Ruby-Applications-in-Elastic-Beanstalk
What solved my problem: I modified the bundle install script and added the --deployment flag
I run rails s or bundle exec rails s and I get this warning:
Bundler is using a binstub that was created for a different gem.
This is deprecated, in future versions you may need to `bundle binstub rails` to work around a system/bundle conflict.
What does this mean? From looking around the bundler site, my understanding of binstubs is that you can set executables to them, so instead of running bundle exec blabla you can just do bin/blabla. So this error is saying my bundler isn't set to the right binstub?
When I run the bundle binstub rails I get this output
rails has no executables, but you may want one from a gem it depends on.
railties has: rails
bundler has: bundle, bundler
I do not understand what my system is trying to tell me, and it's not breaking anything, but I have a hunch this could turn into a bigger issue if I don't fix it
ruby 2.0.0p247
which ruby
/Users/evan/.rvm/rubies/ruby-2.0.0-p247/bin/ruby
which bundler
/Users/evan/.rvm/gems/ruby-2.0.0-p247/bin/bundler
Rails 4.0.2
Edit:
So, if I run the commands in the nag message:
bundle config --delete bin # Turn off Bundler's stub generator
rake rails:update:bin # Use the new Rails 4 executables
I end up getting uninitialized constant Bundler errors with bundle exec commands and the only way I've found to fix that is to rerun bundle install --binstubs which brings back the nag message at the start of this post.
What worked for me was
rm -rf bin/*
Then open a new terminal session and
bundle exec rake app:update:bin
Solution in my case: - Other solutions didn't work for me.
In your Rails directory:
mv /usr/bin/rails /usr/bin/rails.old
bundle config --delete bin
rm -rf bin
# for rails 4.x:
rake rails:update:bin
# for rails 3.x:
bundle install --binstubs
# if you're using rbenv
rbenv rehash
rm -rf ~/.rbenv/plugins/{rbenv-bundle-exec,rbenv-gemset,bundler}
Also be sure that bin/rails is added to the path like:
PATH=./bin:$PATH
Good luck.
This error may raise when you update your ruby but not the related gems.
To check if this is your case, try to make a new rails app in a new empty directory (to be sure RVM is not autoloading any gemset)
make /tmp/test && cd test && rails new test
If this fails stating that it cannot find a suitable 'rails', then simply run
gem update
and overwrite any conflicting rails.
gem uninstall bundler
gem install bundler
Uninstalling all my versions of Bundler, and then installing the latest version fixed it for me. I had multiple versions of bundler installed, so when I ran bundle exec rails s I think the wrong Bundler was used, giving me the warning message.
You may need to generate new stubs after reinstalling Bundler, but I didn't have to.
I was able to fix this by looking at the commit history for bin/rails using git log -p bin/rails
The current, error producing content is:
#!/usr/bin/env ruby
#
# This file was generated by Bundler.
#
# The application 'rails' is installed as part of a gem, and
# this file is here to facilitate running it.
#
require 'pathname'
ENV['BUNDLE_GEMFILE'] ||= File.expand_path("../../Gemfile",
Pathname.new(__FILE__).realpath)
require 'rubygems'
require 'bundler/setup'
load Gem.bin_path('railties', 'rails')
The original, non-error content was:
#!/usr/bin/env ruby
APP_PATH = File.expand_path('../../config/application', __FILE__)
require_relative '../config/boot'
require 'rails/commands'
When I restored the original bin/rails content, the warning message disappeared. Previous attempts had returned uninitialized constant Bundler errors on all bundle exec commands, but now they work. It's worth noting that the original content appears to be exactly what rails new blabla generates in rails 4.0.x.
Still, I would like to know why the first code block causes issues because it's exactly what bundle install --binstubs generates.
Edit: turns out this solution does not work. Pushed this fix to a heroku staging server and heroku errors on startup: all bin/rails commands throw uninitialized constant Bundler and heroku starts up with bin/rails server ..... so this is a not really a fix.
Edit2:
If I add these two lines to the second block (the original bin/rails content), all bin/rails commands are working again:
require 'rubygems'
require 'bundler/setup'
My guess is that the second line is what fixes the bundler errors I was having.
Interestingly, when I tried to edit the first block of code in this post to try and debug which line was throwing the warning, any change I made caused all rails commands to failure, with no information except for the nag note in the OP. weird.
Final bin/rails that fixed my issue:
#!/usr/bin/env ruby
APP_PATH = File.expand_path('../../config/application', __FILE__)
require_relative '../config/boot'
require 'rubygems'
require 'bundler/setup'
require 'rails/commands'
Any additional insight from people who find this would be welcome!
am on a rubymotion project
have required afmotion in rake file, gem file and bundle installed. I get the above error when I try to run rake pod:install.
Any ideas? Thanks in advance.
Make sure you have the cocoapods gem installed, then run
pod setup
If for some reason that doesn't solve the problem, remove the cocoapods directory entirely with
rm -rf ~/.cocoapods and try to pod setup again.
I am trying to capify a project and when I run bundle exec cap staging -T
I get a warning
/usr/local/Cellar/rbenv/0.4.0/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/sshkit-0.0.34/lib/sshkit.rb:3: warning: already initialized constant SSHKit::StandardError
/usr/local/opt/rbenv/versions/2.0.0-p247/lib/ruby/gems/2.0.0/gems/sshkit-0.0.34/lib/sshkit.rb:3: warning: previous definition of StandardError was here
and then the output of the command including the list of tasks
cap deploy # Deploy a new release
cap deploy:check # Check required files and directories exist
...
I have tried removing all the other gems from bundler that would conflict with this but it seems like bundler itself locks this file at versions 2.6.6. I dont even know if it is bundler causing that problem.
Current version of sshkit is 1.3.0. Try running
$ bundle update
and write if you will still have problems. Sometimes the command:
$ gem outdated
can be useful for detecting old versions of gems.
It probably a problem related to symlinks inside rvm/rbenv/… it could be resolved avoiding require_relative inside the sshkit gem but in the meanwhile I think the only option is stick with the error and wait for this issue to be resolved.
I want to write a unit test to check if the Gemfile.lock in my project matches the Gemfile in case I forget to call bundle before committing.
Is there an option for the bundle command (or another method) to check this?
Note that bundle check does not suit this purpose. It checks to see if all gems in the Gemfile are installed on the local system, but it does not check the Gemfile.lock. Therefore the bundle install --deployment command on the server can fail even if bundle check succeeds on the development machine or in CI.
Try:
cp Gemfile.lock Gemfile.lock.orig
bundle install
diff Gemfile.lock Gemfile.lock.orig && echo "Gemfile.lock matches Gemfile"
Use bundle check command
Check searches the local machine for each of the gems requested in the
Gemfile. If all gems are found, Bundler prints a success message and
exits with a status of 0. If not, the first missing gem is listed and
Bundler exits status 1.
The Gemfile generally doesnot match with the Gemfile.lock becoz the bunder would resolve all the dependencies of the Gem and would place them under name of the Gem in the tree fashion. Moreover, the purpose of Gemfile.lock is simply to resolve the version numbers and other dependencies in case of any conflict which may arise when Bunder finds a number of compatible gems during bundle install.
When you perform the bundle update command, the Gemfile.lock is removed and a new Gemfile.lock is generated with new dependencies...