Engine -> Framework roll failed on _macros package error

[zanderso]

Starting with the engine roll here #147999, the roll fails with the error message:

Because macros >=0.1.0-main.3 <0.1.0-main.4 depends on _macros 0.1.3 from sdk which doesn't match any versions, macros >=0.1.0-main.3 <0.1.0-main.4 is forbidden.
So, because flutter_tools depends on macros 0.1.0-main.3, version solving failed.

from https://ci.chromium.org/ui/p/flutter/builders/try/Linux%20analyze/78492/overview.

That engine contained one unrelated commit and the Dart roll here flutter/engine#52677. I have stopped the Dart -> Engine roll, and I'm reverting that Dart roll.

[zanderso]

The Dart roll is being reverted here flutter/engine#52683

[zanderso]

Looks like the only thing that Dart roll might contain that could affect this is the roll of the native repo at https://github.com/dart-lang/native/commits/main/ cc @dcharkes.

[dcharkes]

That would surprise me, we don't usepackage:_macros or dart:_macros at all in dart-lang/native packages.

A commit more likely to have caused this: https://dart-review.googlesource.com/c/sdk/+/365720 cc @jakemac53

My hunch would be that some other packages have to be updated to 0.1.4.

[dcharkes]

cc @scheglov

[jakemac53]

It looks like package:macros is being pinned now by the flutter repo.

This is going to be incredibly problematic, I don't have a suggestion other than not pinning it.

[jakemac53]

Just to elaborate, the package is effectively pinned by the Dart SDK as well. So now flutter/dart always have to be 100% aligned to get a version solve.

Given that the package will be effectively pinned already (by virtue of being pinned to a single Dart SDK), can we put an exception in the tool that does the pinning to just stick in any or something here?

[jakemac53]

One alternative would be baking in some step to the roll process which updates package dependencies as necessary.

Note that the analyzer and _fe_analyzer_shared packages also maintain tighter constraints on this package, and there will be times where they must be updated with a Dart roll into the framework, since flutter also pins analyzer and _fe_analyzer_shared.

[jakemac53]

cc @athomas I hear you are a good person to reach out to for helping to drive some longer term resolution here? It would be great if this could be a catalyst for re-evaluating pinned packages as a whole. With the tight coupling of the macros package and the SDK, this is likely going to be a lot more painful for Dart->Flutter rolls going forward.

[zanderso]

fyi @gspencergoog @christopherfujino

[christopherfujino]

@jakemac53 will it be the case that each new published version of package:macros will also increment its pinned package:_macros constraint? If this is the case, I think not constraining package:macros in the Flutter SDK makes sense, since we're effectively pinning it by pinning the Dart SDK (and thus the version of package:_macros).

If this is not the case, my worry about not pinning package:macros is that a new version of package:macros that is published, with slightly different behavior than the previous but the same pinned dependency on package:_macros could lead to a previously tested and working version of the Flutter SDK regressing, and whether or not a user has the regression is dependent on when they ran flutter pub get.

WDYT?

cc @goderbauer

[jakemac53]

@jakemac53 will it be the case that each new published version of package:macros will also increment its pinned package:_macros constraint

Yes, they are always pinned (package:macros has no implementation, it just re-exports package:_macros).

If this is the case, I think not constraining package:macros in the Flutter SDK makes sense, since we're effectively pinning it by pinning the Dart SDK (and thus the version of package:_macros).

Right, this should alleviate the immediate issue.

[christopherfujino]

@jakemac53 will it be the case that each new published version of package:macros will also increment its pinned package:_macros constraint

Yes, they are always pinned (package:macros has no implementation, it just re-exports package:_macros).

Ahh, ok, this makes sense. Let me try to update the update-packages script to not pin package:macros...

[aam]

Removing the pin seems to have resolved the issue, should it be closed?

[zanderso]

The rolls are moving, so I think this can be closed, yes.

[jakemac53]

I do think a separate issue should be opened, because the fix here is not complete.

Specifically, we will almost certainly run into a situation in the near future where a roll requires a bump of the analyzer package, because the macros package version has increased.

cc @scheglov this will end up requiring us to publish analyzer when we make breaking changes to the macros package as well (although we would want that regardless, for regular Dart users, but I don't think we have discussed it).

[scheglov]

OK

[AlexDochioiu]

Is this meant to be fixed? I cannot run latest master from flutter. I am getting:

Downloading Darwin arm64 Dart SDK from Flutter engine c6fecf65fbf385c5e9168c5b40526c9ae998045b...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  200M  100  200M    0     0  27.7M      0  0:00:07  0:00:07 --:--:-- 32.1M
Building flutter tool...
Resolving dependencies... (1.2s)
Because no versions of macros match >=0.1.0-main.0 <0.1.0-main.0 and macros >=0.1.0-main.0 <0.1.0-main.1 depends on _macros 0.1.0 from sdk, macros >=0.1.0-main.0 <0.1.0-main.1
  requires _macros 0.1.0 from sdk.
And because macros >=0.1.0-main.1 <0.1.0-main.2 depends on _macros 0.1.1 from sdk and macros >=0.1.0-main.2 <0.1.0-main.3 depends on _macros 0.1.2 from sdk, macros
  >=0.1.0-main.0 <0.1.0-main.3 requires _macros 0.1.0 or 0.1.1 or 0.1.2 from sdk.
And because macros >=0.1.0-main.3 <0.1.0-main.4 depends on _macros 0.1.3 from sdk and macros >=0.1.0-main.4 <0.1.0-main.5 depends on _macros 0.1.4 from sdk, macros
  >=0.1.0-main.0 <0.1.0-main.5 requires _macros 0.1.0 or 0.1.1 or 0.1.2 or 0.1.3 or 0.1.4 from sdk.
And because analyzer >=6.5.0 depends on macros >=0.1.0-main.0 <0.1.1 and macros >=0.1.0-main.5 depends on _macros 0.1.5 from sdk, analyzer >=6.5.0 requires _macros 0.1.0 or
  0.1.1 or 0.1.2 or 0.1.3 or 0.1.4 or 0.1.5 from sdk.
So, because _macros from sdk doesn't exist (could not find package _macros in the Dart SDK) and flutter_tools depends on analyzer 6.5.0, version solving failed.
Error: Unable to 'pub upgrade' flutter tool. Retrying in five seconds... (9 tries left)

[AlexDochioiu]

CC @zanderso

[jakemac53]

It sounds like analyzer 6.5.0 was rolled before a Dart SDK was rolled which contains _macros? Either that or something with your setup specifically is a bit weird, do you have a custom flutter engine by chance which needs to be updated?

[AlexDochioiu]

It sounds like analyzer 6.5.0 was rolled before a Dart SDK was rolled which contains _macros? Either that or something with your setup specifically is a bit weird, do you have a custom flutter engine by chance which needs to be updated?

@jakemac53 I tried both a fresh copy of flutter from the official website (changed to master channel) as well as cloning the repo directly. Both of them start giving errors after running flutter channel master (even this command itself starts giving errors after downloading the dart sdk). And I cannot run anything on them, not even "flutter doctor" or "flutter --version".

I also tried to manually delete multiple times the bin/cache directory.

Not sure if relevant, but that's on a macbook pro running m1 max.

[gspencergoog]

I just tried updating Flutter to the latest ref on master (6067d8f), and I can't reproduce the problem (also on a Macbook Pro M1 Max, but I doubt that matters).

Maybe try nuking your .pub-cache directory too?

[gspencergoog]

And @AlexDochioiu if you would be so kind as to file a separate issue, we can track it easier that way, since it doesn't seem directly related to this issue.

[AlexDochioiu]

@gspencergoog I tried to remove .pub-cache too but I get the same thing. I create this ticket for the issue: #148701

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.