New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not try to install gems that are not compatible #968
Comments
This is dependent upon the information being available in the index. This work is being performed by @indirect |
This has been causing me so much pain for so long that I worked out a solution for Ruby 1.9. Here's my environment:
Here's a demonstration of the problem:
I also need to show you this at this stage so you know I'm not cheating later:
Here's my fix:
Here's what happens after applying it:
Trouble is, by default, gem install only considers the latest version. To get it to try others, you need to give it a --version that doesn't start with >, like this:
If invoked with such a constraint, gem fetches all the gemspec files. That's slow. I guess that'll be why the project developers don't want to encourage you to install this way, but wanted to wait for some proper data structure to arrive. The speed isn't bad enough for me to care. It's nowhere near as long as the time for installing ri and RDoc for eg but especially google-api-client. (I would normally use --no-ri and --no-rdoc - who looks for documentation anywhere but Google? - but, to make the examples simpler, I left them off.) I do this once per server. It's more important to me that this automated installation keeps working in the face of gem updates that I don't particularly need. Another trouble is that the function I shimmed has a different signature in eg Ruby 2.1, but I haven't had these compatibility problems there... yet. The fix does, though, apply to Ruby 1.9.3 in Debian Wheezy and, with fuzz, to Ruby 1.9.2 in Debian Squeeze and Debian Lenny. Yes, yes, I know - it's 2016, why am I still using such old versions? I hope there are others, like the OP, in a similarly ancient boat, or I've bored you with this large issue hijack to no avail, sorry! |
That --version '< 999999' only causes find_gems_with_sources to consider all available candidates for the gem mentioned on the command line, not any gems that it might depend on and so on down the dependency tree. That's now bitten me, causing me to run with this too:
|
Oh, when I was here a year ago, I thought this had already been fixed properly upstream and that I was only still having problems because I was stuck with a version from the stone age. Now it's afflicting me with Ruby 2.1, I've contrived a bodge for that version. First, though, a backport of my above bodge to Ruby 1.8:
For Ruby 2.1, doing roughly the same was necessary, I think for the gems on the command line, but sadly not sufficient, I think for dependencies thereof. Here's both stuck together:
|
I've taken the Ruby 2.1 patch from @martindorey and ported it to Ruby 2.3. The latter uses Molinillo as a dependency resolver, so that necessitated a slight reworking of the patch. Here it is:
|
This is an unfortunate long standing issue which we have never managed to fix yet. Solving this is still in the roadmap, and there's a newer ticket tracking this very same problem, so I'll close this old ticket in favour of that one, since it should contain more up to date information. |
for example on ruby 1.8.7:
instead it should try to find a compatible version and install that
The text was updated successfully, but these errors were encountered: