Dependency issues while trying to run legacy projects with Flutter 2 (issue with i18n support) #77491
Comments
|
Had a similar situation. Even wondered if it would a good idea to create a project setting called “flutter version” to easily manage incremental updates and flutter changes. |
|
if you want to use flutter 2 and face such issues, update all packages to latest versions. if you still get errors, use |
|
It's a never ending game of wack-a-mole. I tried to get rid of all the unmaintained deps and I end up with an incompatibility between the latest version of google_fonts and the latest version of Firebase, both maintained by Google. This is insane. |
|
Hi @sarbogast flutter_localizations:
sdk: flutterOf other dependencies, please try to upgrade them to their latest version and see if that works for you. |
|
I am trying to be able to run my flutter app on the newest Flutter. After some version fiddling I am ending up with: again both packages are maintained by Google. Unfortunately, I can't see an easy way out of this. |
|
@pedromassango I already tried that and I'm getting the same issue as @lukeurban: 2 packages maintained by Google incompatible with each other: You can try it for yourself with my project here. All the dependencies are up-to-date, and |
|
As suggested above, you can use dependecy overrides to avoid those conflicts! |
Those packages are not part of the Flutter team's packages (they are third-party package/plugins), I would suggest you to file an issue in their related repositories and probably close this issue. For Firebase related issues: For Google Fonts: I don't think there is much the Flutter team can do to help with this. |
Ideally yes; the null-safety transition makes this much more challenging than usual though. In this case if the SDK constraint could be relaxed to allow either |
|
@kevmoo In discussion with Hixie, he suggested that rather than trying to adjust the framework, we could see about querying for packages that depend on |
|
SGTM!
…On Tue, Mar 9, 2021 at 12:21 PM stuartmorgan ***@***.***> wrote:
@kevmoo <https://github.com/kevmoo> In discussion with Hixie, he
suggested that rather than trying to adjust the framework, we could see
about querying for packages that depend on intl 0.16, and trying to reach
out to them about doing minor updates that would just use 0.17 instead. Is
that feasible?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#77491 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAEFCSFZAW63CVVWSWGMOTTCZYLPANCNFSM4YXGEEZQ>
.
|
... and other packages as well. As a example the |
hi @sarbogast did you managed to resolve this? I had the same issue with firebase_analytics 7.1.0 and google_fonts 2.0.0. But there were new releases for FlutterFire dependencies a few days ago and I managed to resolve this by updating firebase_analytics to 7.1.1. |
|
I have another issue with firebase packages flutterfire#5322. @benedictkhoo I am still waiting for the solution. @pedromassango my app is live and I don't want to rush into temporary solutions as dependency overrides. I wish it to be resolved with a viable dependency connection. I'll wait with my upgrade. But thank you very much for the suggestion! ;) |
This comment has been minimized.
This comment has been minimized.
|
Re-opening to track the ecosystem upgrade that needs to happen. |
|
Note that you can override The root of the problem here though is sdk vendored packages which have pub package dependencies. NNBD definitely highlights this because of the large number of packages with breaking changes, but it will always be a potential version lock problem. Note that this is regardless of pinning or version constraints (in this case it would have been a That is a very difficult problem to solve, but if we want to resolve the core issue that is the place to start IMO. |
Yes, that was @Hixie's take as well.
What's the actionable step for the Flutter project here? It's not clear to me what we can do with this issue (given that I believe we've ruled out hotfixing Flutter 2 to allow |
|
@amirh had written a tool that was "like Rosie but for GitHub" - I wonder if we might be able to drive some updates to the newer intl in the ecosystem, since in some cases it may trivially pass without substantive code updates? |
|
There's at least one breaking change in called out in @kevmoo Have you run the 0.16 query discussed above? Do we know how many packages are still using 0.16? |
|
I figured out how to extract this data from the pub APIs. The most common values are: Then there's a long tail that account for the rest. (Note that the 0.15.x versions already haven't been compatible with Flutter for a while, so are presumably not maintained or widely used.) So by raw numbers, the ecosystem is less than 50% migrated. This isn't taking into account popularity though, so it's hard to translate that to real-world impact. |
|
If we could get popularity, I'd be willing to jump on a few 3P PRs for popular packages that are on ^0.16.1 to help them migrate. |
|
I don't think that information is public, so we'd need to enlist pub.dev folks. My guess though is that popular packages have already heard from users. |
The popularity metric as a score between 1 and 0 is public. The API isn't stable, so it may break at any time, example:
|
|
Any updates here? |
|
Sorting by popularity, the top ten plugins that are using something older than 0.17 (number in parentheses is its place on the list of all
@kevmoo Can we just fix (I'm skeptical about the utility of this sort, given that the one with the highest popularity score has been broken since well before Flutter 2.) |
|
angular and angular_components are...tough. We need to get test passing
with all of the latest stuff.
Hoping to spend a bit more time here this week.
…On Tue, Apr 13, 2021 at 7:41 PM stuartmorgan ***@***.***> wrote:
Sorting by popularity, the top ten plugins that are using something older
than 0.17 (number in parentheses is its place on the list of all intl
dependencies sorted by popularity:
- flutter_money_formatter (32): ^0.15.8—Apparently abandoned, and
doesn't work with previous stable versions of Flutter either.
- angular (33): ^0.16.0—Has a fix on master, but unpublished
- dash_chat (36): ^0.16.0—Has a fix on master, but unpublished
- angular_components (41) ^0.16.0
- webfeed (45): ^0.16.0
- bezier_chart (46): ^0.16.0
- horizontal_calendar_widget (56): ^0.16.1
- flutter_clean_calendar (63): ^0.16.1
- commons (64): ^0.16.1
- flutter_calendar (68): ^0.16.0
@kevmoo <https://github.com/kevmoo> Can we just fix angular and
angular_components?
(I'm skeptical about the utility of this sort, given that the one with the
highest popularity score has been broken since well before Flutter 2.)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#77491 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAEFCUCYEKEQCX2WM4FNGLTIT6GXANCNFSM4YXGEEZQ>
.
|
|
I don't think there is a reason to depend on both |
|
...that, too!
…On Wed, Apr 14, 2021 at 8:42 AM Jacob MacDonald ***@***.***> wrote:
I don't think there is a reason to depend on both angular and flutter in
the same project is there? If that assumption that is correct then these
shouldn't be affected by flutter package dependencies.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#77491 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAEFCXBS3A4N7SJJDE3E3LTIWZVZANCNFSM4YXGEEZQ>
.
|
|
What is actionable here at this point? I'm eager for us to make progress but it's not clear to me what progress actually looks like here. |
|
I don't know how many apps are Otherwise, it's a matter of going after these other big blockers and getting them to migrate – right? |
I think the issue is whether we know what the "big blockers" actually are. It seems very unlikely that an abandoned project to format money that didn't work in Flutter 1.20 either is actually a major blocker, but it's at the top of the popularity sort. @jonasfj How much do we trust that the popularity score reflects real, current usage? |
|
@stuartmorgan There are lots of caveats to our current popularity metrics. On pub.dev we count transitive a weight of 0.1 and direct dependencies with a weight of 1, so getting that metadata wrong probably increased the popularity metric for a lot of packages like win32 and ffi which are frequently fetched as transitive dependencies. If you look at things that depend on package:ffi, ordered by popularity you'll see: The thing is that we only count requests going to pub.dev, and this depends a lot on client behavior. Just saying: there are many ways in which these numbers aren't perfect. We are working to build better metrics in the future. If you have a specify package you're wondering about it might be worth looking at what depends on it.. maybe something there is popular. I can also go digging through a few logs to see what Dart / Flutter versions is using if that's interesting. |
Jonas helped me dig into the numbers on this a bit, and it looks like the correct interpretation is not that the sort is wrong, but that the high end of that sort just isn't actually that high; there are so many packages that being 94% doesn't actually mean there are all that many users. And looking at the issue tracker for the project, many of the bugs are about the compat issue with So it seems like the take-away from the list we have is that we don't actually have big blockers. Instead we have a long tail, which means there's not much we can reasonably do here; the LSC seems like the only thing that would have appreciable impact, but as mentioned above I don't see this as a safe candidate for an LSC. My suggestion is that we close this as unactionable, unfortunately. We may want to file an issue about trying to come up with a generic solution for the problem of pinning third-party dependencies in the framework though, as this has happened before (like the 0.15/0.16 mismatch in the package above) and will happen again, even though it won't be at the scale of the Flutter 2/NNBD impact unless a similar ecosystem-wide migration happens again. @Hixie, thoughts? |
|
Seems reasonable. Let's keep an eye out for whether something needs to change though. |
|
Filed #81472 to consider whether we can reduce this kind of problem in the future. |
|
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 |
Steps to Reproduce
Here is a project I created with Flutter 1.22.6 and I am now trying to build with Flutter 2.0.1. It runs fine with Flutter 1.22.6. Unfortunately I can't even get to run
flutter runwith 2.0.1,because flutter pub getfails with the following error:I used this guide on all my projects to implement internationalization, which is why all my projects depend on intl and flutter_localizations. But apparently Flutter 2 required version 0.17.0 of intl. So I upgrade this dependency to 0.17.0, and comment out dependency on date_time_picker that still needs to be updated to depend on intl 0.17.0, now I'm getting the following dependency issue:
So now pretty much all of my Firebase dependencies need to be updated to be compatible with intl 0.17.0. Which I do, and now I'm getting an issue with url_launcher:
So now I'm trying to update url_launcher to 6.0.2 so that it is compatible with Flutter 2. But now I'm getting an issue with google_fonts, so I update this one as well, but this one conflicts with validators that's not been updated. And it goes on and on like that and I can't get my build to run anymore.
And I see that on other similar projects, simply because flutter_localizations embedded in Flutter 2 depends on intl 0.17.0 which is incompatible with so many other dependencies.
For now, I downgraded Flutter to 1.22.6 so that my projects can build again. But is the solution just to wait for all the dependencies to be updated. Shouldn't old projects still build with the new version of Flutter without this?
Logs
The text was updated successfully, but these errors were encountered: