Every action in a rails console (rails server, rails console, db:migrate, etc.) raises a warning since my last bundle update:
[fog][WARNING] Unable to load the 'unf' gem. Your AWS strings may not be properly encoded.
I'm sure I didn't change anything in the AWS strings which are in my application.rb file:
# Amazon S3 credentials
ENV["AWS_ACCESS_KEY_ID"] = "AWS_ACCESS_KEY_ID"
ENV["AWS_SECRET_ACCESS_KEY"] = "AWS_SECRET_ACCESS_KEY"
ENV["AWS_S3_BUCKET"] = "my-bucket"
I don't have this "unf" gem in my gemfile. Should I add it?
Yes, this just happened a few days ago. You can see from the pull request and commit that the unf dependency is optional.
https://github.com/fog/fog/pull/2320/commits
When I updated my current bundle with fog I received the same warnings, and adding
gem 'unf'
does indeed remove the warning without any issues.
If you do not have any S3 buckets/objects that would have not ASCII characters in the names, I think you can safely disregard the warning. We may do something to make it less noisy also, but for now you can ignore or add unf to quiet it down, as #trh pointed out.
I apparently had fog-1.18.0 installed when I saw this error. (Restarting an aws vagrant project I installed a while ago)
My naive attempt at a fix was to start with an upgrade
gem install fog
which upgraded something to fog-1.21.0. As it warned, "This could take a while..."
... and that did not help.
Exactly WHERE to add "gem 'unf'" wasn't clear from the solution voted up here, it seemed to be lib/fog/aws.rb but that was already there when I looked.
gem install unf
appeared to add it somewhere, but the problem did not go away.
I upgraded vagrant itself (1.4.3 to 1.5.1) and THAT didn't fix it.
Eventually, the fix was
vagrant plugin install unf
as I found in a thread at https://github.com/mitchellh/vagrant/issues/2507
I'm not sure if any of my previous fumbling attempts were also necessary, so I noted them here anyway.
Related
So, I have no Ruby experience at all. However, I'm being asked to look after some Ruby on Rails / Ruby source code that was left behind by my predecessor. I'd like to at least get it to install and run within its Docker container.
From what I can tell, it is failing because of the mimemagic problem from a couple of years ago. It has a dependency on mimemagic v0.3.0 . I know the right thing to do would be to move on to the recent versions that have not been yanked. But, with my limited experience with Ruby, I'd like to at least get my predecessor's code to install and run.
Since moving up to the earliest mimemagic that is available (v0.3.7) appears to break other things, I have been trying to install v0.3.0 using the GitHub reference as a work around.
This:
gem 'mimemagic', github: 'mimemagicrb/mimemagic', ref: 'a4b038c6c1b9d76dac33d5711d28aaa9b4c42c66'
complains that I'm transmitting without encryption. It ultimately fails to fetch with a connection time out.
Meanwhile, this:
gem 'mimemagic', git: 'git#github.com:mimemagicrb/mimemagic.git', ref: 'a4b038c6c1b9d76dac33d5711d28aaa9b4c42c66'
complains that the host key verification has failed.
Finally, this gets me a little further:
gem 'mimemagic', git: 'https://github.com/mimemagicrb/mimemagic.git', ref: 'a4b038c6c1b9d76dac33d5711d28aaa9b4c42c66'
but an error later on looks like this:
rake aborted!
Bundler::GitError: The git source https://github.com/mimemagicrb/mimemagic.git is not yet checked out. Please run `bundle install` before trying to start your application
I have this feeling that "quickly getting it to work" isn't a reality and perhaps all of this will take a lot more than the 1-2 days I've spent so far. I just would like to check what the correct gem/git commands are, and if any of the above three are close.
Thank you!
As the error suggests, you must run the bundle install command before starting the application server or accessing the console.
The reference in the Gemfile is added correctly.
gem 'mimemagic', git: 'https://github.com/mimemagicrb/mimemagic.git', ref: 'a4b038c6c1b9d76dac33d5711d28aaa9b4c42c66'
If you've already executed the mentioned command, can you update the question to have the output for this command?
P.S. Read more about the bundle install command here.
I am setting a new app, stack is:
ruby: 2.6.1 (using rvm)
rails: 5.2.2
bundler: 2.0.1
Now thing is, bundler 2 doesn't use Gemfile at all, i have proper gems.rb and gems.locked and everything was working properly until i pulled some code from a co-worker which got merged.
Issue is whenever i run any rake or rails command i get this error:
/path/to/proj/Gemfile not found
I then even tried going back to old master when that code was not merged and issue is still there. So it is probably not something in the code i pulled.
And issue seems persistent in different machines.
I know there are other issues which have similar errors of Gemfile not found but those are mostly those which had wrong directory opened or some gem issued fixed by bundle update or gem update type commands, this is not that issue because. This is something else, because bundler 2 doesn't even need Gemfile.
It looks like rails doesn't support using gems.rb and gems.locked. https://github.com/rails/rails/issues/31295
You could try what that guy did and edit some files, or you could rename your gems.rb back to Gemfile and gems.locked back to Gemfile.lock
This doesn't seem to have affected anything, it's just irritating in my terminal - I regularly receive the following warning (sometimes I receive multiple, calling out different lines, and sometimes the path after /gem/ varies, but other than that, this is the output:
/Users/alecwilson/.rvm/gems/ruby-2.2.1/gems/fog-1.23.0/lib/fog/rackspace/mock_data.rb:42: warning: duplicated key at line 80 ignored: "name"
It's most common when bundling and running rake test. Any idea on how to fix it? I'm generally pretty wary of editing files in my .rvm directory, as I've royally screwed it up before, and still sometimes get a warning about my PATH being incorrectly set up (but only occasionally). If anyone can walk me through what is causing this, I'd be very grateful.
As #jBeas said in the comments go find the latest fog gem version https://rubygems.org/gems/fog
Then update the fog gem in your rails gemfile, currently your fog gem should be:
gem 'fog', '1.38.0'
This used to be a recurring error for users who had followed along with the Rails Tutorial for Rails 4 where the Tutorial guided the users to use an outdated version of the Fog gem, 1.23.0 (it was the updated version at the time the Rails Tutorial was written).
Now that the rails tutorial has been recently updated for Rails 5 the fog gem is currently up to date: '1.38.0'.
UPDATE for those coming from Rails Tutorial
The latest prevailing wisdom is to use carrierwave-aws gem rather than fog, significantly reducing your app's footprint. The switch took me about 15 minutes and reduced my gem dependencies by 33. Advice taken from Mike Perham, the creator of Sidekiq: http://www.mikeperham.com/2016/02/09/kill-your-dependencies/
I've added added the gem simple-navigation 3.9.0 to my gemfile in rails 3.2.11 and it runs fine in development. However, when I deploy to my production server and try to open a page with the method I get the following error:
undefined method `render_navigation'
I don't believe it's specific to that one gem though, as I had the same problem earlier when I used the uuid gem.
Using $LOADED_FEATURES I find "simple_navigation", so it seems to be loaded.
Info about the production server
nginx 1.2.6
Unicorn 4.5.0
Rubygems 1.8.23
Ubuntu 12.04 LTS
rbenv 0.4.0-9-g045f6c1
EDIT
Other gems work, the server runs fine, except for the above problem.
Make sure your gem is not declared inside the development group in the Gemfile
The gems in the development group are not be loaded in production.
group :development do
gem "simple-navigation"
end
Also, if you have a <APP_HOME>/.bundle/config file, ensure that it doesn't have the BUNDLE_WITHOUT option.
Gemfile
group :ui do
gem "simple-navigation"
end
.bundle/config
---
BUNDLE_WITHOUT: ui
In the above example, the gem group ui will not be loaded.
Having said that I had very-very limited exposure to Rails, I saw similar behavior when Gemfile.lock wasn't committed into repository. As result when project was pushed to production envinronment there was some screw ups with dependency resolution.
Have you try RAILS_ENV=production bundle install ?
While technically not an answer, I decided to switch over to Linode as my host. This involved a complete re-install of my server setup and it's working now. I did the exact same steps installing the server this time as last, so I'm still not sure what was wrong, or if it would have been easily fixable. Since I no longer have the old server available it would be impossible to confirm any solutions proposed from now on.
I'm going to mark this answer as the solution unless there are any objections within the next 48 hours.
I just tried deploying my app to Heroku. It's been working for quite a while, I am just adding some new features. Once I deployed, I got an "App Crashed" error. heroku logs showed No such file to load -- nokogiri (LoadError).
Now, on my system, my Gemfile.lock showed 2 different nokogiri gems: nokogiri (~> 1.5.0), a dependency of fog (1.4.0) and nokogiri (1.5.5-x86-mingw32) which doesn't appear to be a dependency of anything. Under platforms was only x86-mingw32. My development computer is Windows 7 with ruby 1.9.3p194 and the Ruby version that the Heroku toolbalt uses for itself is heroku-toolbelt/2.30.1 (i386-mingw32) ruby/1.9.2.
My version of Bundler was up to date, my version of the Heroku toolbelt was up to date. I tried deleting Gemfile.lock and re-deploying on the advice of some forum posts, but the app was still crashed.
It appears that Heroku was simply not bundling in the right version of nokogiri, but was ignoring it on account of my use of Windows. The way I got to to be fixed was I added gem 'nokogiri', '~> 1.5.5' to my gemfile (even though my app does not explicitly need nokogiri, it is only a dependency) and then re-deployed to Heroku without running bundle install on my own system first. Now the app does not crash.
I have no idea why this worked. I don't know how to ensure the problem doesn't occur again, I just happened to get lucky with a desperate patch. I can't have this downtime in the future, or worry about something like this happening again for a routine deploy. Can someone please explain what was actually wrong and the right way to solve it?
Add this
PLATFORMS
x86-mingw32
to your Gemfile. Heroku will then ignore your Gemfile.lock because windows has crazy different dependencies.