Skip to content
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

Closed
Fryguy opened this issue Apr 16, 2024 · 4 comments · Fixed by #7607
Closed

Introducing a new gem fails to bundle update with existing platform-specific gem #7585

Fryguy opened this issue Apr 16, 2024 · 4 comments · Fixed by #7607
Labels

Comments

@Fryguy
Copy link
Contributor

Fryguy commented Apr 16, 2024

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 then bundle 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

  1. Create a Gemfile as follows:

    source 'https://rubygems.org'
    gem "nokogiri", ">=1.16.4"
  2. bundle update. It will succeed and produce the following Gemfile.lock:

    GEM
      remote: https://rubygems.org/
      specs:
        nokogiri (1.16.4-aarch64-linux)
          racc (~> 1.4)
        nokogiri (1.16.4-arm-linux)
          racc (~> 1.4)
        nokogiri (1.16.4-arm64-darwin)
          racc (~> 1.4)
        nokogiri (1.16.4-x86-linux)
          racc (~> 1.4)
        nokogiri (1.16.4-x86_64-darwin)
          racc (~> 1.4)
        nokogiri (1.16.4-x86_64-linux)
          racc (~> 1.4)
        racc (1.7.3)
    
    PLATFORMS
      aarch64-linux
      arm-linux
      arm64-darwin
      x86-linux
      x86_64-darwin
      x86_64-linux
    
    DEPENDENCIES
      nokogiri (>= 1.16.4)
    
    BUNDLED WITH
       2.6.0.dev
    
  3. Modify the Gemfile as follows:

    source 'https://rubygems.org'
    gem "nokogiri", ">=1.16.4"
    gem "prism", ">=0.25.0"
  4. bundle update will fail with the following error:

    Resolving dependencies...
    Resolving dependencies...
    Fetching gem metadata from https://rubygems.org/.......
    Could not find gems matching 'nokogiri (= 1.16.4)' valid for all resolution platforms () in rubygems repository https://rubygems.org/, cached gems or
    installed locally.
    
    The source contains the following gems matching 'nokogiri (= 1.16.4)':
      * nokogiri-1.16.4-aarch64-linux
      * nokogiri-1.16.4-arm-linux
      * nokogiri-1.16.4-arm64-darwin
      * nokogiri-1.16.4-java
      * nokogiri-1.16.4
      * nokogiri-1.16.4-x64-mingw-ucrt
      * nokogiri-1.16.4-x64-mingw32
      * nokogiri-1.16.4-x86-linux
      * nokogiri-1.16.4-x86-mingw32
      * nokogiri-1.16.4-x86_64-darwin
      * nokogiri-1.16.4-x86_64-linux
    
  5. rm -f Gemfile.lock

  6. bundle update again will now succeed and produce the following Gemfile.lock:

    GEM
      remote: https://rubygems.org/
      specs:
        nokogiri (1.16.4-aarch64-linux)
          racc (~> 1.4)
        nokogiri (1.16.4-arm-linux)
          racc (~> 1.4)
        nokogiri (1.16.4-arm64-darwin)
          racc (~> 1.4)
        nokogiri (1.16.4-x86-linux)
          racc (~> 1.4)
        nokogiri (1.16.4-x86_64-darwin)
          racc (~> 1.4)
        nokogiri (1.16.4-x86_64-linux)
          racc (~> 1.4)
        prism (0.25.0)
        racc (1.7.3)
    
    PLATFORMS
      aarch64-linux
      arm-linux
      arm64-darwin
      x86-linux
      x86_64-darwin
      x86_64-linux
    
    DEPENDENCIES
      nokogiri (>= 1.16.4)
      prism (>= 0.25.0)
    
    BUNDLED WITH
       2.6.0.dev
    

    Diff from previous Gemfile.lock

    diff --git a/Gemfile.lock.before b/Gemfile.lock
    index c8b6a99..7fbd46c 100644
    --- a/Gemfile.lock.before
    +++ b/Gemfile.lock
    @@ -13,6 +13,7 @@ GEM
           racc (~> 1.4)
         nokogiri (1.16.4-x86_64-linux)
           racc (~> 1.4)
    +    prism (0.25.0)
         racc (1.7.3)
    
     PLATFORMS
    @@ -25,6 +26,7 @@ PLATFORMS
    
     DEPENDENCIES
       nokogiri (>= 1.16.4)
    +  prism (>= 0.25.0)
    
     BUNDLED WITH
        2.6.0.dev

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 below

Environment

Bundler       2.6.0.dev
  Platforms   ruby, arm64-darwin-22
Ruby          3.2.3p157 (2024-01-18 revision 52bb2ac0a6971d0391efa2275f7a66bff319087c) [arm64-darwin-22]
  Full Path   /Users/jfrey/.rubies/ruby-3.2.3/bin/ruby
  Config Dir  /Users/jfrey/.rubies/ruby-3.2.3/etc
RubyGems      3.5.9
  Gem Home    /Users/jfrey/.gem/ruby/3.2.3
  Gem Path    /Users/jfrey/.gem/ruby/3.2.3:/Users/jfrey/.rubies/ruby-3.2.3/lib/ruby/gems/3.2.0
  User Home   /Users/jfrey
  User Path   /Users/jfrey/.gem/ruby/3.2.0
  Bin Dir     /Users/jfrey/.gem/ruby/3.2.3/bin
Tools
  Git         2.42.0
  RVM         not installed
  rbenv       not installed
  chruby      0.3.9

Bundler Build Metadata

Built At          2024-04-16
Git SHA           unknown
Released Version  false

Gemfile

Gemfile

source 'https://rubygems.org'

gem "nokogiri", ">=1.16.4"
gem "prism", ">=0.25.0"

Gemfile.lock

GEM
  remote: https://rubygems.org/
  specs:
    nokogiri (1.16.4-aarch64-linux)
      racc (~> 1.4)
    nokogiri (1.16.4-arm-linux)
      racc (~> 1.4)
    nokogiri (1.16.4-arm64-darwin)
      racc (~> 1.4)
    nokogiri (1.16.4-x86-linux)
      racc (~> 1.4)
    nokogiri (1.16.4-x86_64-darwin)
      racc (~> 1.4)
    nokogiri (1.16.4-x86_64-linux)
      racc (~> 1.4)
    prism (0.25.0)
    racc (1.7.3)

PLATFORMS
  aarch64-linux
  arm-linux
  arm64-darwin
  x86-linux
  x86_64-darwin
  x86_64-linux

DEPENDENCIES
  nokogiri (>= 1.16.4)
  prism (>= 0.25.0)

BUNDLED WITH
   2.6.0.dev
@Fryguy Fryguy added the Bundler label Apr 16, 2024
@Fryguy
Copy link
Contributor Author

Fryguy commented Apr 16, 2024

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.

@Fryguy
Copy link
Contributor Author

Fryguy commented Apr 18, 2024

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

@deivid-rodriguez
Copy link
Member

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.

@deivid-rodriguez
Copy link
Member

#7607 should be ready now to fix this problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants