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/
Related
I am working with Ruby on Rails Tutorial (Third Edition) by Michael Hartl. I am currently in chapter 1 and have been able to download Ruby on Rails-v 4.2.0. I have made all the adjustment within the Gemfile and was successful in connecting to my sever. However, once I closed the server I have not been able to reconnect and get an error message
You cannot specify the same gem twice with different version
requirements. You Specified:sqlite3 (>_0) and sqlite3 (=1.3.9)
I tried to search on Google but did not find the answer. Any help or suggestions would be wonderful!
The error message is saying it all:
You cannot specify the same gem twice with different version requirements. You Specified:sqlite3 (>_0) and sqlite3 (=1.3.9)
You must have mistakenly specified the sqlite3 gem twice in your Gemfile. Remove one of them (possibly the older one), then run:
bundle install
and re-start your rails server.
This should fix your problem.
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.
After I added the devise_rpx_connectable gem to my Gemfile, I cannot run rails server anymore or migrate to add a column to my Users table. I'm trying to follow the railscast example here:
http://railscasts.com/episodes/233-engage-with-devise?view=comments
I have tried several things over the last two days to try getting this thing to work. I've tried creating the migration file myself but when I run 'rake db:migrate --trace' the error I get is "rake aborted! cannot load such file -- devise/schema" and a lot of errors underneath starting with:
C:/.../devise/ruby/1.9.1/gems/activesupport-3.2.6/lib/active_support/dependencies.rb:251 in 'require'
I have tried googling this question and only found a handful of people with the same issue, none of which had their questions answered. Seems other people with 'cannot load such file' errors were told their versions of certain gems weren't compatible so I'll provide that info here:
Gemfile:
gem 'rails', '3.2.6'
gem 'devise', '2.1.2'
gem 'devise_rpx_connectable', '0.2.2'
Also my bundler version is 1.1.4 and my ruby version is 1.9.3
The only thing that stands out to me is that the version of ruby in the devise folder seems to be 1.9.1 and mine is 1.9.3 but I would like to know the possible consequences of downgrading to 1.9.1.
Any input would be greatly appreciated!
Thanks
So we decided to delete the contents of the schema.rb file that "require 'devise/schema.rb'" was in and our app magically worked! I had no idea the implications of this so i did some more research and found this-
https://github.com/nbudin/devise_cas_authenticatable/commit/44aacb23fb5b4cc9d22434c952b9d1d88fe28e88#commitcomment-1555733
turns out that with the newer version (> 2.1) of devise, the contents of this file aren't necessary. hope this solves a lot of other peoples issues, especially if they decide to update the devise gem and continue to use devise_rpx_connectable.
What does this mean? Is my system set for UTF when it should be ASCII or something?
This problem has been nagging me on one of my machines for the past year, and I only solved it just now. The machine in question is an old ASUS laptop running 32-bit Ubuntu 12.04, Ruby 1.9.3, and RVM. I had the same problem running gem update, but only with rake 0.8.7
Sadly, I'm a bit of a newb at this stuff, so I can't quite work it all out, but I ran into two separate issues - inability to update rake beyond 0.8.7, and inability to get the documentation to process correctly. The second problem is the more difficult to understand, but, as I understand it, it results from one particular version of rdoc relying on SourceIndex, which was deprecated in November, 2011.
Both problems are gem-related - character sets in the OS, to name one potential cause, don't seem to be an issue. As best as I can tell, my version of the problem was that my paths weren't correctly set to update the gem program. I'd type "gem update --system" from the prompt and gem would tell me that it was up-to-date, but rake wouldn't update and the characters wouldn't be correctly installed in the documentation for rake, either.
In retrospect, what apparently happened was that the path was set up so that gem update would affect a different version of Ruby than the one I was using under RVM. So, the key is to update the gems you're using by running the update program without having to rely on the path.
The solution has four parts. The first is to uninstall rake.
The second is to update the gems (this also makes it possible to update rake). Usually, this can be done by just typing gem update --system Since I'm using RVM, I did this by going into ~/.rvm/gems/ruby-1.9.3-p194/bin and ran update_rubygems. I suspect that my system fell out of configuration between the path and multiple versions of Ruby. By going directly to the ~/.rvm/gems/ruby-1.9.3-p194/bin directory and running the update_rubygems command,the system was able to update both the correct rdoc gem so it correctly translated the characters, and the correct rake gem, both of which are gems in the rvm-managed version of Ruby.
The third stage is to reinstall rake.
The fourth is the usual suite of testing and hygiene commands - gem clean, gem update, gem list, etc.
I regret not having a better handle on this, but hope this helps.
My question is very similar to How do I freeze gems into a Rails 3 application?, but I only want to freeze a single modified gem. The answers to that question seem to result in bundling all the application's gems.
In case it's relevant, I need to do this so the modified gem gets installed on Heroku.
I checked the bundle-install doc but it didn't seem to address this situation. I can't imagine it's that uncommon, though. Any guidance is appreciated.
Well, Bundler is going to freeze all of them, and the idea is that you want to freeze not only a single gem, but the collection of gems that produced a working copy of your app.
That being said, on your local dev machine, you can do bundle update [name of gem] and it will update just that one gem to the latest version within the restrictions specified in your Gemfile, which also updates your Gemfile.lock, which effectively updates just that one gem on Heroku when you next deploy.
If you're using bundler, which is the default for Rails 3, you can always fork the gem to your own git repository and add that definition to your Gemfile with whatever location it can be found at:
gem 'thegem', :git => 'git://github.com/cloned_to_me/thegem.git'
Another option is to use bundle package to save copies of the gems in vendor/cache. These can then be later installed using bundle install --local according to the documentation.
This is the closest thing to the Rails 2 "freeze" method, but has the added advantage of saving the gems before they are installed, not after, avoiding any platform-specific problems as was the case previously.
With thanks to those who answered the question with related approaches, I ended up going with the approach mentioned in this sister question. For the sake of clarity, this is what I did:
Repackage modified gem as its own gem. This takes a little finagling but is described well in the RubyGems Guides. Move said gem into your source directory (I used vendor/gems)
In the project's Gemfile, point to the location of the new gem:
gem "modified_gem", :path => "vendor/gems/modified_gem"
Add new gem to version control, make sure bundle install isn't messed up with funky settings (e.g. --local), and cross your fingers.
Someone also mentioned that it's possible to mix in changes to the gem instead of overriding source files. I don't know anything more about this technique except that it should be possible.