Closed flavorjones closed 2 years ago
Not urgent at all, obviously, since it's Christmas :)
Just wanted to note that I ran into this when trying to upgrade a project to Ruby 3.1 and running bundle install
:
nokogiri-1.12.5-x86_64-darwin requires ruby version < 3.1.dev, >= 2.5, which is incompatible with the current version, ruby 3.1.0p0
% ruby -v
ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-darwin21]
The platforms in my Gemfile.lock include Ruby, so I'm not sure why Bundler isn't falling back to it automatically like (based on the description of this issue?) it should:
PLATFORMS
ruby
x86_64-darwin-18
x86_64-darwin-19
x86_64-darwin-20
x86_64-linux
The following is my Gemfile and Gemfile.lock:
Anyway, Merry Christmas and again - not urgent at all, just reporting it in case anyone else runs into it or these details help :)
EDIT: I removed these lines from my Gemfile.lock and it seems to be installing fine now:
nokogiri (1.12.5-x86_64-darwin)
racc (~> 1.4)
nokogiri (1.12.5-x86_64-linux)
racc (~> 1.4)
Not urgent at all, obviously, since it's Christmas :)
Just wanted to note that I ran into this when trying to upgrade a project to Ruby 3.1 and running
bundle install
:nokogiri-1.12.5-x86_64-darwin requires ruby version < 3.1.dev, >= 2.5, which is incompatible with the current version, ruby 3.1.0p0
% ruby -v ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-darwin21]
The platforms in my Gemfile.lock include Ruby, so I'm not sure why Bundler isn't falling back to it automatically like (based on the description of this issue?) it should:
PLATFORMS ruby x86_64-darwin-18 x86_64-darwin-19 x86_64-darwin-20 x86_64-linux
The following is my Gemfile and Gemfile.lock:
Gemfile Gemfile.lock Anyway, Merry Christmas and again - not urgent at all, just reporting it in case anyone else runs into it or these details help :)
EDIT: I removed these lines from my Gemfile.lock and it seems to be installing fine now:
nokogiri (1.12.5-x86_64-darwin) racc (~> 1.4) nokogiri (1.12.5-x86_64-linux) racc (~> 1.4)
@connorshea
1- Delete your Gemfile.lock
2 - run bundle install
Note that this will use ruby vanilha platform and not the native one.
We got a similar report on slack, bundler should be handling this fine, but this is tricky stuff and I believe we might not be there yet :( On an initial look, this would seem similar to https://github.com/rubygems/rubygems/issues/4455.
Does bundle update nokogiri
work?
To clarify, Bundler should handle this just fine if there's no Gemfile.lock
file. This problem is specific to having a lockfile generated with a previous Ruby, and thus including platform specific variants of nokogiri not compatible with the running Ruby. That's why @connorshea's smart trick works.
So, I tried to reproduce now and things seem to just work for me, but I tested this under arm64-darwin21
, which is not locked at all, so I guess that's why.
@simi reported that somehow ruby version constraints were by passed for him and 1.12.5-x86_64-linux
got installed under ruby 3.1. I guess that's what's causing the problem for him, but I still have no idea how 1.12.5-x86_64-linux
would get installed under Ruby 3.1 in the first place.
@deivid-rodriguez My project is open source, so you can try reproducing it yourself:
main
branch and bundle install
rbenv local 3.1.0
or switching to the test-branch-for-bundler-issue
branch which has a .ruby-version
file.bundle install
and it should fail.I'm on an M1 Mac, if that matters at all.
Yup,, I managed to reproduce easily with your initial Gemfile, but creating a lockfile from scratch with ruby 3.0 and then bundle it with ruby 3.1. I'm working on a fix now.
This is trickier than it seemed to me in the first place :(
When using gem information from the lockfile, it is initially forbidden to fetch the "real underlying specification" for each gem and we're only allowed to use names, versions, and dependency information recorded in the lockfile. The problem is, required_ruby_version
metadata is not recorded in the lockfile, so we can't check it before resolving in order to figure out whether we need to discard some data in the lockfile due to not satisfying the running ruby version.
To fix the issue I can think of two approaches:
required_ruby_version
metadata in the lockfile. This is what I suggested at rubygems/rubygems#4455 and it seems doable, but requires special backwards compatibility work.required_ruby_version
information. This also sounds doable, but I tried it at https://github.com/rubygems/rubygems/pull/5070 and I couldn't get it to fully work.I'll try hard to figure out some solution.
Thank you for all your great work as always, Deivid 🙇♂️
Oddly, I ran into this issue with only ruby
in the PLATFORMS
section. When I deleted the Gemfile.lock
and ran bundle
it updated PLATFORMS
to be just x86_64-linux
.
Yes, I think that is expected. Even if your lockfile is locked to RUBY, bundler will still try to also resolve for your specific platform, and will run into the same issue.
In my experience, the only reliable way to avoid the aforementioned problems is to use bundle config set force_ruby_platform true
.
I had a similar experience as @mockdeep. I deleted my Gemfile.lock, ran bundle
, and it completed successfully on a Macbook Air M1. My Gemfile.lock diff afterwards was:
PLATFORMS
- ruby
+ arm64-darwin-21
Has someone tried bundle update nokogiri
? I just tried it myself and it worked fine, since it completely avoids the lockfile for nokogiri.
On an intel mac, with several rails applications, deleting the Gemfile.lock
(or bypassing with bundle update nokogiri
) didn't work for me. Following @skaes' advice, however, has produced clean builds with no lockfile diff.
Really? What error did you get? That's completely unexpected and sounds like a similar issue to the one reported by @simi in Slack. If you were able to reproduce that and report an issue to https://github.com/rubygems/rubygems, that'd be great.
@deivid-rodriguez the error I was getting from running bundle install
against an existing Gemfile was:
nokogiri-1.12.5-x86_64-darwin requires ruby version >= 2.5, < 3.1.dev, which is incompatible with the current version, ruby 3.1.0p0
Which is oddly very close to but not exactly what @connorshea reported above (the version bounds are reversed—they had < 3.1.dev, >= 2.5
).
My Gemfile's platforms were simply:
PLATFORMS
ruby
This is exactly my problem, I'll try to dig deeper soon to provide reproducing script.
I'm able to repro with a Gemfile
that simply contains:
source "https://rubygems.org"
gem "nokogiri"
Here's a transcript of working with it:
14:56:41 ~/work/etc/bundletest/ % ls
Gemfile
14:56:50 ~/work/etc/bundletest/ % cat Gemfile
source "https://rubygems.org"
gem "nokogiri"
14:56:59 ~/work/etc/bundletest/ % ruby -v
ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-darwin20]
14:57:03 ~/work/etc/bundletest/ % gem -v
3.3.3
14:57:13 ~/work/etc/bundletest/ % bundle config
Settings are listed in order of priority. The top value will be used.
14:57:21 ~/work/etc/bundletest/ % bundle
Fetching gem metadata from https://rubygems.org/.......
Resolving dependencies...
nokogiri-1.12.5-x86_64-darwin requires ruby version >= 2.5, < 3.1.dev, which is incompatible with the current version, ruby 3.1.0p0
14:57:28 ~/work/etc/bundletest/ % bundle config set force_ruby_platform true
14:57:33 ~/work/etc/bundletest/ % bundle
Fetching gem metadata from https://rubygems.org/.......
Resolving dependencies...
Using bundler 2.3.3
Using racc 1.6.0
Using mini_portile2 2.6.1
Using nokogiri 1.12.5
Bundle complete! 1 Gemfile dependency, 4 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
14:57:40 ~/work/etc/bundletest/ % cat Gemfile.lock
GEM
remote: https://rubygems.org/
specs:
mini_portile2 (2.6.1)
nokogiri (1.12.5)
mini_portile2 (~> 2.6.1)
racc (~> 1.4)
racc (1.6.0)
PLATFORMS
ruby
DEPENDENCIES
nokogiri
BUNDLED WITH
2.3.3
15:00:15 ~/work/etc/bundletest/ % bundle config set force_ruby_platform false
You are replacing the current global value of force_ruby_platform, which is currently "true"
15:00:26 ~/work/etc/bundletest/ % bundle
Using bundler 2.3.3
Using mini_portile2 2.6.1
Using racc 1.6.0
Using nokogiri 1.12.5 (x86_64-darwin)
Bundle complete! 1 Gemfile dependency, 4 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
One thing that jumps out at me is, after I set force_ruby_platform
to false
, the install succeeds again but as Using nokogiri 1.12.5 **(x86_64-darwin)**
@deivid-rodriguez apologies, I'm not sure exactly how to frame this for a rubygems issue. What other info could I provide?
So @simi's issue was that somehow nokogiri-1.12.5-x86_64-linux
got installed in his system on Ruby 3.1, which is completely unexpected since it's not supported there. Somehow required_ruby_version
constraints were bypassed but we don't know how yet. I think your issue is the same, but on MacOS. If you manually uninstall nokogiri-1.12.5-x86_64-darwin
through gem uninstall nokogiri
, it should work again.
The problem, and what we need to be able to reproduce reliably, is how this is happening in the first place.
...
Actually, while I was writing this I think I realized what the problem might be. Let me do some testing and I'll get back to you.
No, not really, I'm unable to reproduce this :(
Yep you're right, after doing gem uninstall nokogiri
(and "yes"ing everything), it behaves great.
@deivid-rodriguez I think I've got something. My initial bundle install
with Ruby 3.1.0 was on a project that used a private gem repository (Artifactory) instead of rubygems. Redoing the basic Gemfile
above allows the platform-specific version to be installed:
16:06:56 ~/work/etc/bundletest/ % gem list | grep nokogiri
16:07:00 ~/work/etc/bundletest/ % ruby -v
ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-darwin20]
16:07:04 ~/work/etc/bundletest/ % gem -v
3.3.3
16:07:07 ~/work/etc/bundletest/ % bundler -v
Bundler version 2.3.3
16:07:12 ~/work/etc/bundletest/ % l
total 16
-rw-r--r-- 1 bencullen-kerney 11 Dec 29 14:37 .ruby-version
-rw-r--r-- 1 bencullen-kerney 84 Dec 29 16:06 Gemfile
16:07:18 ~/work/etc/bundletest/ % cat Gemfile
source "https://XXXXXXX/"
gem "nokogiri"
16:07:23 ~/work/etc/bundletest/ % bundle
Fetching gem metadata from https://XXXXXXX/........
Resolving dependencies...
Using bundler 2.3.3
Using racc 1.6.0
Fetching nokogiri 1.12.5 (x86_64-darwin)
Installing nokogiri 1.12.5 (x86_64-darwin)
Bundle complete! 1 Gemfile dependency, 3 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
16:07:45 ~/work/etc/bundletest/ % gem list | grep nokogiri
nokogiri (1.12.5 x86_64-darwin)
16:07:58 ~/work/etc/bundletest/ % cat Gemfile.lock
GEM
remote: https://XXXXXXX/
specs:
nokogiri (1.12.5-x86_64-darwin)
racc (~> 1.4)
racc (1.6.0)
PLATFORMS
x86_64-darwin-20
DEPENDENCIES
nokogiri
BUNDLED WITH
2.3.3
Unfortunately I'm not very familiar with how the repository is configured, but happy to dig in where I can.
Also apologies for continuing this thread—this is clearly not a nokogiri-specific bug. I'm honestly not sure it's a rubygems bug, or if the private repository is misconfigured somehow.
My problem was with Geminabox private repo, but I have seen it using rubygem.org as well.
@simi did you gem uninstall nokogiri
between the two? It seems that, once the platform-specific version is allowed through, it will reproduce for Gemfiles with the rubygems source.
Yeah, maybe this should be moved to our repository. I think the culprit is here:
The actual filtering of required_ruby_version
is only done for EndpointSpecification
s, which represent the data given by the Compact Index API. Older APIs provide RemoteSpecification
objects, which did not include required_ruby_version
information. And custom gem servers like Geminabox only support older APIs as far as I know.
Has someone tried
bundle update nokogiri
?
I tried that and it didn't fix the issue. I needed to regenerate Gemfile.lock
.
Hi, although this conversation is valuable, I'd prefer if it didn't happen here and instead happened on a bundler issue. @deivid-rodriguez can you recommend somewhere this can continue?
Please don't run bundle config set force_ruby_platform true
to work around problems. Instead uninstall all nokogiri versions from your system and re-bundle.
See #2408 for status on shipping 3.1 support in native precompiled gem releases.
@flavorjones Yes, I'm so sorry for hijacking this thread with a bundler issue. I created a fresh ticket in our repository: https://github.com/rubygems/rubygems/issues/5251. Let's post any comments about that issue there.
I hope this isn't adding noise. On MBP M1. No Gemfile.lock file has yet been created. New Rail 7 app
➜ gem install nokogiri
Building native extensions. This could take a while...
Successfully installed nokogiri-1.12.5
1 gem installed
app_name on main [?] via 💎 ruby-3.1.0 took 42s
➜ bundle update
Fetching gem metadata from https://rubygems.org/...........
Resolving dependencies...
nokogiri-1.12.5-arm64-darwin requires ruby version >= 2.5, < 3.1.dev, which is incompatible with the current version, ruby 3.1.0p0
Tried
➜ bundle update nokogiri
This Bundle hasn't been installed yet. Run `bundle install` to update and install the bundled gems.
Thanks everyone for working on this
@MtnBiker please uninstall all versions of nokogiri and try again.
@MtnBiker also please make sure "ruby" is a platform that bundler is including in your Gemfile.lock under the PLATFORMS section. Use bundler lock --add-platform ruby
if you need to.
@flavorjones and others. Thank you. I sorted it out. I think the problem was that Rails 7.0.0 wasn't compatible with Ruby 3.1.0. So went with another version of Ruby. Ran into another problem with pg. Lots of activity on Rails, but in response tot the 3.1.0 problem: "This is already fixed on main - #43951. It was expected for rails 7.0.1 to be released before ruby 3.1.0. See https://bugs.ruby-lang.org/issues/14394#note-36." But current release still at 7.0.0. And mentions of Ruby 3.2 in Issues
Oh that nokogiri issue is about ruby 3.1, from a year ago, not ruby 3.2. Still, it explains how nokogiri is "supposed" to work, and combined with the 1.14.0.rc1 release notes -- I think it is exactly what is going on now with ruby 3.2, it explains everything else I've been seeing.
Everywhere else, bundler figures out not to use the pre-compiled nokogiri, which is why I haven't had any problems with it in those other environments -- and noticed nokogiri taking longer to install, compiling from source!
But on samvera CircleCI builds, nope. And I suspect the custom caching routines in our samvera orb.
This is a placeholder to ship a new version of Nokogiri with Ruby 3.1 precompiled native support.
Please note that Nokogiri supports Ruby 3.1, but until a precompiled native gem is shipped, you will have to use the
ruby
vanilla platform gem which will compile from source during installation. Modernbundler
will do this for you automatically.This work is currently waiting for a version of rake-compiler-dock with Ruby 3.1 build capabilities. The maintainers of that project are aware, and there is no need to bother them. Feel free to subscribe to this issue and I'll keep it updated.
See #2408 for status.