Skip to content

Conversation

@christopherfujino
Copy link
Contributor

@christopherfujino christopherfujino commented May 16, 2022

Fixes #102781

Previously, flutter update-packages --force-upgrade command would:

  1. Crawl the flutter/flutter repo, collecting the set of all pub packages depended on
  2. Create a synthetic pub package, populated with all the packages from step 1
  3. For manually pinned packages, the pinned version would be used; else, each package version would be set to any
  4. Run pub get on the synthetic package, allowing pub to version solve and determine the "best" version solution
  5. Backfill the exact versions resolved by pub get on the synthetic packages to the actual pubspec.yaml files in the repo.

The problem with this algorithm is that the "best version solution" algorithm from step 4 that pub get uses is a heuristic that can sometimes result in certain packages getting downgraded relative to the previous run (see #102781 (comment) for more details).

This PR solves the problem by substituting >= $prevVersion for any in step 3. This will preclude pub from consideration a solution that would downgrade a package.

@flutter-dashboard flutter-dashboard bot added the tool Affects the "flutter" command-line tool. See also t: labels. label May 16, 2022
@christopherfujino christopherfujino marked this pull request as ready for review May 16, 2022 20:57
Copy link
Contributor

Choose a reason for hiding this comment

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

The || is extra it falls under the last else

Copy link
Member

Choose a reason for hiding this comment

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

I think if doUpgrade is true, and version = 'any', then without the ||, we could end up with versionToUse = '>= any'". Not sure if pub would like that.

Copy link
Contributor

Choose a reason for hiding this comment

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

Right, then the || is fine

Copy link
Contributor

Choose a reason for hiding this comment

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

I have a general question about private methods. Is it ok to make them public as long as you add the visibleForTesting? Quoting Dan in this answer "if it's something worth testing, it's something that's worth being public". Regardless of the answer this is a nit/curiosity

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think it's a nice goal to strive for to only test public methods. However, this command would be incredibly difficult to end to end test. Also, this synthetic package gets created and deleted during the running of the command, so it would not really be practical to test after the command completed (the behavior we're interested in is also dependent on a heuristic algorithm inside the pub binary).

As for making this function public, I couldn't think of a reason we would ever need to call this function (other than in tests) in another library, and if we later do, we can always mark remove the annotation. The main drawback to using @visibleForTesting is that it is effectively public to any downstream users who don't gate their code on the analyzer, but we don't have to worry about that with the tool.

Copy link
Contributor

@Jasguerrero Jasguerrero left a comment

Choose a reason for hiding this comment

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

LGTM with the nit

Copy link
Member

Choose a reason for hiding this comment

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

I think if doUpgrade is true, and version = 'any', then without the ||, we could end up with versionToUse = '>= any'". Not sure if pub would like that.

@fluttergithubbot
Copy link
Contributor

This pull request is not suitable for automatic merging in its current state.

@fluttergithubbot fluttergithubbot merged commit 586b15c into flutter:master May 19, 2022
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request May 19, 2022
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request May 19, 2022
@christopherfujino christopherfujino deleted the upgrade-only branch May 19, 2022 21:36
engine-flutter-autoroll added a commit to engine-flutter-autoroll/plugins that referenced this pull request May 21, 2022
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Aug 30, 2022
engine-flutter-autoroll added a commit to engine-flutter-autoroll/plugins that referenced this pull request Aug 30, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

tool Affects the "flutter" command-line tool. See also t: labels.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[flutter_tools] flutter update-packages downgrades package:coverage

4 participants