In both, the Gemfile and in Gemfile.lock there's nothing about oauth2 (=0.5.0) , both are set to 0.4.1
Where is this dependency written?
Here's end of output from bundle install
Bundler could not find compatible versions for gem "oauth2":
In snapshot (Gemfile.lock):
oauth2 (0.4.1)
In Gemfile:
diaspora-client depends on
oauth2 (= 0.5.0)
I faced this problem before, for my case, i just reinstall everything using a network where there is no firewall or any restriction. Previously i use a network with alot of restriction, then it keep give me error. After I change network, all work perfectly fine.
Related
I am trying to deploy a webapp in Ruby 3.0.2 and Rails 7.0.1 and I have a problem after deploying it via capistrano in a production server Ubuntu 20.04 with nginx(1.18.0) and passenger(6.0.12).
All the processes work fine but the app can not start in production. I get the passenger error page. Finding in logs I get the next error:
"Error: The application encountered the following error: You have already activated io-wait 0.1.0, but your Gemfile requires io-wait 0.2.1. Since io-wait is a default gem, you can either remove your dependency on it or try updating to a newer version of bundler that supports io-wait as a default gem"
I have tried to remove the gem io-wait but is a default system gem and I cannot remove it, I have upgraded the bundler to the latest (2.3.4) and the error persists. I have added the latest io-wait version (0.2.1) and got the same error.
Any help will be welcome.
I got it to work by adding
gem "io-wait", "0.1.0"
I then also had the problem with "strscan". Had to downgrade to "3.0.0".
I was able to get things going by using the following:
gem "io-wait", "0.2.0"
In my gem file I set the two offending gems to the old versions.
gem "io-wait", "0.1.0"
gem "strscan", "3.0.0"
After that, deploying and booting the app worked fine.
Ruby v3.0.2
Rails 7.0.0
Specifically, this commit has been merged into mongomapper master to fix a bug that is causing my application to crash:
https://github.com/mongomapper/mongomapper/pull/572
However, it hasn't been released in a new gem. Is it possible to include it prematurely or do I have to wait until it's released? I'm on heroku with a Gemfile.lock that specifies version.
My gemfile.lock currently reads:
mongo_mapper (0.13.0)
activemodel (>= 3.0.0)
activesupport (>= 3.0)
mongo (~> 1.8)
plucky (~> 0.6.5)
I don't know about Heroku, but if you want to use a git version of a gem that is not on Rubygems yet, you must add the git path to your Gemfile.
In your Gemfile change:
gem 'mongomapper'
To:
gem 'mongomapper', :git => 'https://github.com/mongomapper/mongomapper.git'
Or if you're on a more modern ruby, you can also use:
gem 'mongomapper', github: 'mongomapper/mongomapper'
And of course after that you must run bundle install or bundle update mongomapper.
Since the Ruby code isn't compiled, if you have the notes for that patch you can always manually add those changes to the lib directory of the mongomapper gem, although I can't advise against this enough - it's undesirable to change the source code, especially underneath an installed gem.
Once you go down this road you can't really count on any support for related issues until you are updated to a newer version or reverted to the original files.
I am working on a gem and it's on github.
When I include the gem in an application, do a capistrano deploy, and (on the server) run:
bundle outdated
I see:
* authengine (0.0.1 d8baa49 > 0.0.1 de43dfa)
which tells me that a more recent commit is available. Why doesn't the bundle update (part of capistrano deploy) pull the more recent version? There is no version constraint in the Gemfile of the host application, and anyway they have the same version number, just different commits.
Even if I log into the server and run
bundle update authengine
I get the same "outdated" result afterwards.
What am I missing here?
One thing I've found that can cause this is if other gems in the bundle make requirements on gems by version that are incompatible. Bundler tries to reconcile these by selecting versions of gems such that their requirements can all be satisfied. The result is that it quietly refuses to update gems.
The way to check this is to set an explicit version requirement in your Gemfile. Something like
gem "authengine", "> 0.0.2" #(you'll need to bump the version to make this work)
#or
gem "authengine", :ref => "d8baa49"
Then run
bundle update authengine
You should see something like (this is taken from my particular case):
Bundler could not find compatible versions for gem "json": In
Gemfile:
chef (> 10.8) ruby depends on
json (<= 1.6.1, >= 1.4.4) ruby
logical-construct (>= 0) ruby depends on
json (1.7.5)
So, in my case it's a problem with explicitly requiring a newer version of json.
The author, André Arko, stated in 2014 that:
The Bundler resolver is definitely a work in progress, and we adjust
the tradeoffs between specific versions and resolving quickly based on
user feedback.
Bundler has consistently not provided the newest possible version of
every gem for the entirety of its existence, and it does result in a
lot of tickets being opened. In most cases, it turns out to be the
result of Bundler having to pick between the newest version of one gem
or a different gem, and Bundler picks the gem the user doesn’t care
about having the newest version of. That’s why it’s so important to
make your Gemfile version requirements accurately reflect your actual
requirements.
I recognize that your assumption that Bundler would give you the
newest possible version seemed valid at the time, but the docs only
say that you will get a version that meets your requirements, not the
latest. Is there anywhere we could expand the docs to make it clearer
that the newest versions of everything simply isn’t feasible?
What is the output returned when you run bundle update authengine? Does it actually say it updated the gem? Or does it ignore the gem?
You can try using the --source parameter to specifically tell Bundler to use the git repository. That, or your
bundle update authengine --source https://github.com/mustardseeddatabase/authengine.git
Also, when unexpected things like this happen, I like to clean up my gemlist in general. It could be that you still have older versions of the gem laying around, not using in bundler.
So you could do:
gem list
gem check
gem cleanup
Or do a complete reinstall
gem uninstall authengine
bundle install
I am trying to install chiliproject on a server, following the -well done- documentation I am hitting this error
Could not find gem 'rubytree (~> 0.5.2) ruby' in any of the gem sources listed in your Gemfile.
I did a gem install rubytree
I get this message
========================================================================
Thank you for installing rubytree.
WARNING: SIGNIFICANT API CHANGE in 0.8.0 !
------------------------------------------
Please note that as of 0.8.0 the CamelCase method names are DEPRECATED.
The new method names follow the ruby_convention (separated by '_').
The old CamelCase methods still work (a warning will be displayed),
but may go away in the future.
Details of the API changes are documented in the API-CHANGES file.
========================================================================
Successfully installed rubytree-0.8.1
1 gem installed
Installing ri documentation for rubytree-0.8.1...
file 'COPYING,API-CHANGES' not found
Installing RDoc documentation for rubytree-0.8.1...
file 'COPYING,API-CHANGES' not found
That is saying the installation was succesful. So why do I get the error ?
If the error is from the API change how can I request version 0.5.2 of the rubytree gem ?
When I do a gem list --local | grep 'rubytree'
I have this output rubytree (0.8.1)
So why is the system saying could not find gem 'rubytree' ?
thank you for any help,
Depending on what version of rails you are using (and it sounds like you are using a relatively newer one, if it's prompting you for your Gemfile), then you need to use Bundler to manage your gems.
Try editing your Gemfile, adding a new line that reads:
gem "rubytree", "< 0.6"
Then open up a console, and type this command
bundle install
This should fix your problems, but if you still get errors when running a command, then try typing bundle exec prior to the command (i.e. rails server becomes bundle exec rails server).
Currently, we require rubytree exactly in version 0.5.2 or 0.5.3, as specified in our Gemfile, the 0.8.1. version you installed by hand will not suffice that requirement, which is exactly what the error message states.
What seems a bit odd is the literal ruby in the error message. Could you please make sure that you have the exact unchanged Gemfile from the source on your system? Also, could you please remove any user-installed plugins and try again? Also, which ruby (type and version) on which operating system are you using?
I installed Bundler on a pre-Rails 3 application and am trying to use it to install gems. My Gemfile contains the following lines:
source :rubygems
[...]
gem "RubyInline", "3.8.1"
However, when I run bundle install I get this error:
Fetching source index for http://rubygems.org/
Could not find gem 'RubyInline', required by 'memcache-client (= 1.6.3)', in any of the sources
The gem appears on the rubygems website:
http://rubygems.org/gems/RubyInline
Why is it giving me an error then?
I'm afraid this resolved itself after changes to fix other issues, and I'm not sure what the fix was. The source of several other issues was wrong permissions on various gems/binaries.
This kind of issue for me seems to be resolved on occasion by applying
bundle update
before
bundle install
The effect is to resolve old dependencies from when the bundle was originally produced and hence a gem that has been superseded (or whatever) will no longer be in the Gemfile.