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
Introducing a new gem fails to bundle update with existing platform-specific gem #7585
Comments
This was the smallest reproducer I could come up with showing the issue. However, I think it's useful to note that my larger reproducers had different output when the bundle update failed. In some cases it would say "could not find gems matching 'prism...", and then list all of the prism gems. Yet another case I was using a git-based gem, and it chose that gem to say it couldn't find matches for. I'm not sure why it decided to choose "random" gems for the error message. I felt that was too much tangential detail for this particular issue though and didn't want to confuse the reproduction, and so left those out, but it might be an important detail. |
I had a couple colleagues try this, and those on Mac M1s got it to fail, but not those on AMD x86_64 Linux, so I presume that being on an arm architecture is affecting this. I'm trying to build a Dockerfile to demonstrate, but not having much luck. EDIT: Updated the OP with this info |
Thanks! Yes, I tried this yesterday but noticed that even on Linux, platforms are incorrectly deleted from the lockfile. So it may be the same issue with a different manifestation. Working on a fix now. |
#7607 should be ready now to fix this problem. |
Describe the problem as clearly as you can
I'm not exactly sure what is going on, but given a Gemfile with an existing platform dependent gem, when I introduce a new gem, then
bundle update
fails. However, subsequently deleting the Gemfile.lock and thenbundle update
again works fine with no discernible reason in the Gemfile.lock differences.Did you try upgrading rubygems & bundler?
Yes. I have recreated this with Ruby 3.1 and 3.2 (latest rubygems) on various versions of bundler from 2.5.0 up to 2.5.9 as well as on 2.6.0-dev HEAD (1e97357). I cannot reproduce this with bundler 2.4.22, which makes me think it's a bug in the new platform handling code introduced in 2.5.0.
Note that I had a couple colleagues try this, and those on Mac M1s got it to fail, but not those on AMD x86_64 Linux, so I presume that being on an arm architecture is affecting this. I'm trying to build a Dockerfile to demonstrate, but not having much luck.
The steps below are with Ruby 3.2 and bundler 2.6.0-dev HEAD (1e97357)
Post steps to reproduce the problem
Create a Gemfile as follows:
bundle update
. It will succeed and produce the following Gemfile.lock:Modify the Gemfile as follows:
bundle update
will fail with the following error:rm -f Gemfile.lock
bundle update
again will now succeed and produce the following Gemfile.lock:Diff from previous Gemfile.lock
Which command did you run?
bundle update
What were you expecting to happen?
I did not expect resolution to fail, but even if it did fail, I expected it to also fail after removal of the Gemfile.lock, which it did not.
What actually happened?
The resolution fails, but upon removal of the Gemfile.lock it succeeds.
If not included with the output of your command, run
bundle env
and paste the output belowEnvironment
Bundler Build Metadata
Gemfile
Gemfile
Gemfile.lock
The text was updated successfully, but these errors were encountered: