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

Bundler 2: [Prerelease] Add version resolver #3319

Merged
merged 5 commits into from
Mar 24, 2021

Conversation

feelepxyz
Copy link
Contributor

@feelepxyz feelepxyz commented Mar 22, 2021

Add native helpers for bundler 2 version resolver.

Added two pending specs as they require the LatestVersionFinder.

TODO

  • Add specs when bundler 2 version is specified
  • Add specs when updating gems that require a specific major version of bundler, e.g. guard-bundler

@feelepxyz feelepxyz changed the title WIP: Bundler 2 version resolver Bundler 2: [Prerelease] Add version resolver Mar 23, 2021
@feelepxyz feelepxyz marked this pull request as ready for review March 23, 2021 11:23
@feelepxyz feelepxyz requested a review from a team as a code owner March 23, 2021 11:23

let(:dependency_files) { project_dependency_files("bundler2/bundler_specified") }

it "returns nil as resolution returns the bundler version installed by core" do
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

@feelepxyz feelepxyz Mar 23, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bummer, it doesn't seem like we can currently update bundler at all.

When running a dry-run to update a gemfile with bundler v1 it tries to go to v2 even though the project has been bundled with v1, it looks like it falls through here atm: https://github.com/dependabot/dependabot-core/blob/main/bundler/helpers/v1/lib/functions/version_resolver.rb#L24 because bundler isn't listed as one of the gems in the definition.

When running the v2 helpers, bundler is listed as a gem but we return nil if the gem name is bundler, I think this is the best thing for now as the "resolved version" is core's bundler version, not the latest resolvable version.


let(:dependency_files) { project_dependency_files("bundler2/requires_bundler") }

pending "resolves version" do
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These specs require the LatestVersionFinder and all the dependency source native helpers to be added so left these as pending until we have that merged in.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be able to remove pending once this is in #3327

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll do this downstream in a separate PR 👍

let(:dependency_files) do
project_dependency_files("bundler1/imports_gemspec_version_clash_old_required_ruby_no_lockfile")
end
let(:gemfile_fixture_name) { "imports_gemspec_version_clash" }
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unused

end
let(:current_version) { "3.0.1" }

it "raises a DependencyFileNotResolvable error" do
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Previously it looked like bundler v1 ignores the minimum ruby version in the gemspec (see spec above), I think this new behaviour is correct as the currently installed version of statesman doesn't satisfy the ruby version in the project gemspec.

@@ -2074,98 +2074,4 @@
it { is_expected.to eq(false) }
end
end

context "with bundler 2 support enabled" do
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All these specs fail because the v2 version resolver is used and returns errors.

@@ -1708,29 +1708,4 @@
end
end
end

context "with bundler 2 support enabled" do
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These specs fail because the v2 version resolver is used and returns errors.

@@ -8,11 +8,11 @@ def index
if ruby_version
requested_version = ruby_version.to_gem_version_with_patchlevel
sources.metadata_source.specs <<
Gem::Specification.new("ruby\0", requested_version)
Gem::Specification.new("Ruby\0", requested_version)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like it changed here: rubygems/rubygems@4e950f5

@jurre jurre merged commit 495b7ab into main Mar 24, 2021
@jurre jurre deleted the feelepxyz/bundler2-version-resolver branch March 24, 2021 14:18
end
end

context "when bundled with v2 and requesting a version that requires bundler v1", :bundler_v2_only do
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jurre looks like this spec is not actually raising, not sure there's anything wrong with that though so probably just a bogus test case that can be removed.

let(:dependency_files) { project_dependency_files("bundler2/requires_bundler") }

pending "resolves version" do
expect(subject.version).to eq(Gem::Version.new("3.0.0"))
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be expect(subject[:version]).to eq(Gem::Version.new("3.0.0"))

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cheers 👍

@thepwagner thepwagner mentioned this pull request Mar 25, 2021
deivid-rodriguez added a commit to deivid-rodriguez/dependabot-core that referenced this pull request Mar 18, 2022
Up until the Bundler 2 upgrade, when in the context of updating a
library, dependabot would first try locking the Ruby version according
to the minimum ruby requirement specified in the gemspec (if any). If
that fail, dependabot would retry without any ruby version locking by
detecting a specific error message raised by Bundler. This feature was
introduced by fcd5682.

However, when the upgrade to Bundler 2 happened, the related spec
started failing, because the string to look for within Bundler's error
message was not updated to match what Bundler 2 was raising (error
message was changed upstream at
rubygems/bundler#6647).

Instead, the spec was updated to match the new result (see
dependabot#3319 (comment)).

In the spec, dependabot is updating a Gemfile including

```ruby
gem 'statesman', "~> 3.0.0"
```

in combination with a gemspec including

```ruby
required_ruby_version ">= 1.9.3"
```

Statesman 3.0.0 has a Ruby ">= 2.2" requirement, so it does not support
Ruby 1.9.3 already. The original dependabot behaviour was to ignore the
preexisting mismatch and move on. That makes sense to me, there's some
reasons why a library main have this situation. In my case, I have
several Gemfiles testing different major versions of my dependencies
(Rails, in particular), and some of them don't support the oldest Ruby
supported by my gem (my Rails 7 gemfile does not support my oldest
supported Ruby, 2.6).

On a more pragmatic point of view, the old behavior didn't cause any
reported issues that I know of, while the new behavior did bite my
particular case.

So this commit changes the expectation to what it used to be and updates
the strings to look for in error messages to support both Bundler 1 and
Bundler 2 error messages.
deivid-rodriguez added a commit to deivid-rodriguez/dependabot-core that referenced this pull request Mar 18, 2022
Up until the Bundler 2 upgrade, when in the context of updating a
library, dependabot would first try locking the Ruby version according
to the minimum ruby requirement specified in the gemspec (if any). If
that fail, dependabot would retry without any ruby version locking by
detecting a specific error message raised by Bundler. This feature was
introduced by fcd5682.

However, when the upgrade to Bundler 2 happened, the related spec
started failing, because the string to look for within Bundler's error
message was not updated to match what Bundler 2 was raising (error
message was changed upstream at
rubygems/bundler#6647).

Instead, the spec was updated to match the new result (see
dependabot#3319 (comment)).

In the spec, dependabot is updating a Gemfile including

```ruby
gem 'statesman', "~> 3.0.0"
```

in combination with a gemspec including

```ruby
required_ruby_version ">= 1.9.3"
```

Statesman 3.0.0 has a Ruby ">= 2.2" requirement, so it does not support
Ruby 1.9.3 already. The original dependabot behaviour was to ignore the
preexisting mismatch and move on. That makes sense to me, there's some
reasons why a library main have this situation. In my case, I have
several Gemfiles testing different major versions of my dependencies
(Rails, in particular), and some of them don't support the oldest Ruby
supported by my gem (my Rails 7 gemfile does not support my oldest
supported Ruby, 2.6).

On a more pragmatic point of view, the old behavior didn't cause any
reported issues that I know of, while the new behavior did bite my
particular case.

So this commit changes the expectation to what it used to be and updates
the strings to look for in error messages to support both Bundler 1 and
Bundler 2 error messages.
deivid-rodriguez added a commit to deivid-rodriguez/dependabot-core that referenced this pull request Mar 18, 2022
Up until the Bundler 2 upgrade, when in the context of updating a
library, dependabot would first try locking the Ruby version according
to the minimum ruby requirement specified in the gemspec (if any). If
that fail, dependabot would retry without any ruby version locking by
detecting a specific error message raised by Bundler. This feature was
introduced by fcd5682.

However, when the upgrade to Bundler 2 happened, the related spec
started failing, because the string to look for within Bundler's error
message was not updated to match what Bundler 2 was raising (error
message was changed upstream at
rubygems/bundler#6647).

Instead, the spec was updated to match the new result (see
dependabot#3319 (comment)).

In the spec, dependabot is updating a Gemfile including

```ruby
gem 'statesman', "~> 3.0.0"
```

in combination with a gemspec including

```ruby
required_ruby_version ">= 1.9.3"
```

Statesman 3.0.0 has a Ruby ">= 2.2" requirement, so it does not support
Ruby 1.9.3 already. The original dependabot behaviour was to ignore the
preexisting mismatch and move on. That makes sense to me, there's some
reasons why a library main have this situation. In my case, I have
several Gemfiles testing different major versions of my dependencies
(Rails, in particular), and some of them don't support the oldest Ruby
supported by my gem (my Rails 7 gemfile does not support my oldest
supported Ruby, 2.6).

On a more pragmatic point of view, the old behavior didn't cause any
reported issues that I know of, while the new behavior did bite my
particular case.

So this commit changes the expectation to what it used to be and updates
the strings to look for in error messages to support both Bundler 1 and
Bundler 2 error messages.
deivid-rodriguez added a commit to deivid-rodriguez/dependabot-core that referenced this pull request Mar 18, 2022
Up until the Bundler 2 upgrade, when in the context of updating a
library, dependabot would first try locking the Ruby version according
to the minimum ruby requirement specified in the gemspec (if any). If
that fail, dependabot would retry without any ruby version locking by
detecting a specific error message raised by Bundler. This feature was
introduced by fcd5682.

However, when the upgrade to Bundler 2 happened, the related spec
started failing, because the string to look for within Bundler's error
message was not updated to match what Bundler 2 was raising (error
message was changed upstream at
rubygems/bundler#6647).

Instead, the spec was updated to match the new result (see
dependabot#3319 (comment)).

In the spec, dependabot is updating a Gemfile including

```ruby
gem 'statesman', "~> 3.0.0"
```

in combination with a gemspec including

```ruby
required_ruby_version ">= 1.9.3"
```

Statesman 3.0.0 has a Ruby ">= 2.2" requirement, so it does not support
Ruby 1.9.3 already. The original dependabot behaviour was to ignore the
preexisting mismatch and move on. That makes sense to me, there's some
reasons why a library main have this situation. In my case, I have
several Gemfiles testing different major versions of my dependencies
(Rails, in particular), and some of them don't support the oldest Ruby
supported by my gem (my Rails 7 gemfile does not support my oldest
supported Ruby, 2.6).

On a more pragmatic point of view, the old behavior didn't cause any
reported issues that I know of, while the new behavior did bite my
particular case.

So this commit changes the expectation to what it used to be and updates
the strings to look for in error messages to support both Bundler 1 and
Bundler 2 error messages.
jeffwidman added a commit that referenced this pull request Nov 22, 2022
Per the discussion in #3319 (comment), these only temporarily needed to be marked `pending` until #3327 was merged.

From the first thread it looks like the intent was to remove the `pending` comment, but that accidentally got overlooked.

So this removes them.
jeffwidman added a commit that referenced this pull request Nov 23, 2022
Per the discussion in #3319 (comment), these only temporarily needed to be marked `pending` until #3327 was merged.

From the first thread it looks like the intent was to remove the `pending` comment, but that accidentally got overlooked.

So this removes them.
jeffwidman added a commit that referenced this pull request Jan 23, 2023
Per the discussion in #3319 (comment), these only temporarily needed to be marked `pending` until #3327 was merged.

From the first thread it looks like the intent was to remove the `pending` comment, but that accidentally got overlooked.

So this removes them.
jeffwidman added a commit that referenced this pull request Jan 23, 2023
Per the discussion in #3319 (comment),
these only temporarily needed to be marked `pending` until
#3327 was merged.

From the first thread it looks like the intent was to remove the
`pending` comment, but that accidentally got overlooked.

So this removes them, and then fixes the failures.

One test was straightforward change from method to hash value.

But the other was a logical change from expecting a raised error to
expecting no error. However, this has been true since this code was
originally committed (once #3327 was merged to make the test work):
https://github.com/dependabot/dependabot-core/pull/3319/files#r600526250

I considered removing it, but thought it didn't hurt to continue to keep
it in to ensure no regressions... it is a `bundler 2` test, so still
valid even after we drop support for `bundler 1`.
jeffwidman added a commit that referenced this pull request Jan 23, 2023
Per the discussion in #3319 (comment),
these only temporarily needed to be marked `pending` until
#3327 was merged.

From the first thread it looks like the intent was to remove the
`pending` comment, but that accidentally got overlooked.

So this removes them, and then fixes the failures.

One test was straightforward change from method to hash value.

But the other was a logical change from expecting a raised error to
expecting no error. However, this has been true since this code was
originally committed (once #3327 was merged to make the test work):
https://github.com/dependabot/dependabot-core/pull/3319/files#r600526250

I considered removing it, but thought it didn't hurt to continue to keep
it in to ensure no regressions... it is a `bundler 2` test, so still
valid even after we drop support for `bundler 1`.
jeffwidman added a commit that referenced this pull request Jan 24, 2023
Per the discussion in #3319 (comment),
these only temporarily needed to be marked `pending` until
#3327 was merged.

From the first thread it looks like the intent was to remove the
`pending` marker, but that accidentally got overlooked.

So this removes the `pending` marker, and then fixes the failures:
1. The first was a straightforward change from method to hash value.
2. The second wasn't raising the expected error... However, this has
   been true since [this code was originally committed](https://github.com/dependabot/dependabot-core/pull/3319/files#r600526250)
   (once #3327 was merged to make the test work). So I deleted the test
   as it added no value.
jeffwidman added a commit that referenced this pull request Jan 24, 2023
Per the discussion in #3319 (comment),
these only temporarily needed to be marked `pending` until
#3327 was merged.

From the first thread it looks like the intent was to remove the
`pending` marker, but that accidentally got overlooked.

So this removes the `pending` marker, and then fixes the failures:
1. The first was a straightforward change from method to hash value.
2. The second wasn't raising the expected error... However, this has
   been true since [this code was originally committed](https://github.com/dependabot/dependabot-core/pull/3319/files#r600526250)
   (once #3327 was merged to make the test work). So I deleted the test
   as it added no value.
alcere pushed a commit that referenced this pull request Feb 20, 2023
Per the discussion in #3319 (comment),
these only temporarily needed to be marked `pending` until
#3327 was merged.

From the first thread it looks like the intent was to remove the
`pending` marker, but that accidentally got overlooked.

So this removes the `pending` marker, and then fixes the failures:
1. The first was a straightforward change from method to hash value.
2. The second wasn't raising the expected error... However, this has
   been true since [this code was originally committed](https://github.com/dependabot/dependabot-core/pull/3319/files#r600526250)
   (once #3327 was merged to make the test work). So I deleted the test
   as it added no value.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants