search

rydmike / flex_color_scheme

A Flutter package to make and use beautiful color scheme based themes.
Other
890 stars 100 forks source link

version solving failed for flutter_localizations and flex_color_scheme #133

Closed esbozos closed 1 year ago

esbozos commented 1 year ago

I'm not sure if it's my mistake or I missed something updating the packages. But I have two days trying to run my app and apparently the only way is to downgrade flex_color_scheme to version 4, but then I lose many properties of the app with material 3.

Flutter version:

pubspec.yaml


dependencies:
  flutter:
    sdk: flutter
  cupertino_icons: ^1.0.2
  flutter_localizations:
    sdk: flutter
  intl: ^0.18.0
  go_router: ^6.0.8
  googleapis: ^10.1.0
  provider: ^6.0.5
  url_launcher: ^6.1.9
  flex_color_scheme: ^7.0.1
  dio: ^5.0.0
  cached_network_image: ^3.2.3
  transparent_image: ^2.0.1
  json_annotation: ^4.8.0
  flutter_secure_storage: ^8.0.0
  settings_ui: ^2.0.2
  google_fonts: ^4.0.3
  jiffy: ^6.1.0
  country_picker: ^2.0.20
  syncfusion_flutter_charts: ^21.1.35
  flutter_svg: ^2.0.4

Flutter run:

Resolving dependencies... (1.0s)
Because flex_seed_scheme 1.2.3 depends on material_color_utilities ^0.2.0 and no versions of flex_seed_scheme match
  >1.2.3 <2.0.0, flex_seed_scheme ^1.2.3 requires material_color_utilities ^0.2.0.
And because every version of flutter_localizations from sdk depends on material_color_utilities 0.3.0,
  flutter_localizations from sdk is incompatible with flex_seed_scheme ^1.2.3.
And because flex_color_scheme 7.0.1 depends on flex_seed_scheme ^1.2.3 and no versions of flex_color_scheme match >7.0.1
  <8.0.0, flutter_localizations from sdk is incompatible with flex_color_scheme ^7.0.1.
So, because arkadu_admin depends on both flutter_localizations from sdk and flex_color_scheme ^7.0.1, version solving
  failed.

Note: the app was fully functional and in fact I compiled it a couple of weeks ago without problems and published in play store.

rydmike commented 1 year ago

Hi @esbozos,

You observation is correct, I was wondering when someone would notice.

The reason is because flex_color_scheme 7.0.x depends on material_color_utilities ^0.2.0 and flutter stable 3.7.x and up and until very recently also flutter beta and master depended on exact version material_color_utilities 0.2.0. However, a few days ago both flutter beta and master 3.10.x-pre, changed and started using material_color_utilities 0.3.0.

This causes an unresolvable version conflict when one tries to use flex_color_scheme on beta and master channels. This is because material_color_utilities for some reason insists on using a zero ver version number.

When a version level starts with "0.x.y" in semantic versioning (https://semver.org/) and particularly in pub.dev package resolving, a change in "x" is considered a breaking change. When you use, none zero start version, e.g. "1.x.y" a change in "x" is considered a feature addition release that is not breaking. So when you do e.g. "^1.2.0" a bump in package to package version "1.3.0" would have been OK and covered by the package version constraint resolving, but since it is "^0.2.0" to "0.3.0" it cannot be resolved, since the change is considered breaking and there is no common version ground to be found.

I do not know why the Google Material team insists on using zero-ver for the critical material_color_utilities package, and it is indeed critical, because the Flutter sdk itself depends on it to deliver Material 3 colors. If you check pubsepc.yaml for Flutter itself, it does not contain a lot of packages, but a few and one is material_color_utilities. Currently Flutter is in transition from using 0.2.0 in stable to 0.3.0 in beta and master, causing this conflict.

Personally I think the latest material_color_utilities version, since it uses zero-ver, should have called the 0.3.0, version 0.2.1 instead, and we would not be having this conflict and issue between Flutter stable 3.7.x and beta/master 3.10.x.

I checked and I did not find any mention of any breaking changes in material_color_utilities version 0.3.0, over 0.2.0, (see change log https://pub.dev/packages/material_color_utilities/changelog) only fixes and new features. So it should have been version 0.2.1 since they use zero ver. If they would be on none zero version, the bump in minor number would have been correct, but for a zero-ver package it is incorrect usage of semantic version, so Google authors of the package material_color_utilities are kind of behind this a bit messy conflict. Perhaps there is also some breaking change in the package, that is just not mentioned in its changelog, but if so, that would also be very poor practice, since it is not mentioned in the changelog.

I have tested and used the flex_color_scheme package myself fine on current stable/beta/master channels by adding a dependency override for material_color_utilities. Since there does not seem to be any broken APIs in material_color_utilities in version 0.3.0 from 0.2.0, flex_color_scheme, works just fine when it uses 0.3.0 as well. You can thus do the following in your application's pubspec.yaml without any issues:

Temp FIX: Use a dependency override for material_color_utilities

dependency_overrides:
  material_color_utilities: '>=0.2.0 <0.4.0'

To manually resolve the version conflict. After this you can build on all channels again, including current beta and master. I am currently using this myself too.

I think I will during the weekend release new versions of flex_color_scheme, flex_seed_scheme and flex_color_picker that all use the above version constraint for their material_color_utilities dependency. Then they can all be used on all current flutter channels, without adding the above dependency override.

Until then and for an immediate fix before these versions are released, please use the above dependency override on Flutter beta and master channels 3.10.0-x.

Sadly there is no way to know in advance when the material_color_utilities authors decides to follow semantic versioning practices and not. The only way seems to be to as soon as there is new version out of it, to manually examine if is broken or not, and if not then change the version constraint for used material_color_utilities version in the packages ot cover it if possible. In this case the above constraint is OK and is as far as I can currently safely extend it. It was however impossible to know this in advance, since it is not a version constraint that would normally be usable if material_color_utilities authors actually used semantic versioning correctly.

Hope this helps 😃

rydmike commented 1 year ago

I will keep this issue open until I have released version 7.0.2 of flex_color_scheme that avoids this issue by using the above mentioned version constraint for material_color_utilities. I will need to first release versions of flex_seed_scheme and flex_color_picker that do the same with their material_color_utilities dependencies.

esbozos commented 1 year ago

Thanks @rydmike I was just testing changing the flutter channel and had managed to get past the dependency issue; however, with other CocoaPods issues cropping up. But now, I'm back to the main flutter channel and applying your solution, it works like a charm. Just flutter run and I have the app running again. Thank you very much. I had already exhausted myself looking everywhere for references on how to overcome this dependency problem.

I will watch for updates to remove this dependency override when appropriate.

rydmike commented 1 year ago

Glad if it helped.

And BTW and yes, unrelated to this issue or FlexColorScheme at all, I have noticed when using master channel and I think probably now on beta as well (since it is quite fresh and have most of master things in it), that when I switch back to stable channel, I can no longer build e.g. a macOS target, I get a world of coco pods issues I cannot figure out either.

I noticed that master/beta runs some script that changes things in the macOS embedder/runner folder, so when you switch back to stable channel you have a /macos runner that is incompatible with current Flutter stable release.

What I did then was delete the macos folder and recreate it with stable release using flutter create . to get one made with stable channel again. Naturally you have to use a git diff to revert and put back custom things like entitlements, icons, window name etc, after doing that.

So yes it is a bit painful at the moment to switch back from beta/master to stable channel.

BTW, I think current beta version is fairly close to what will be in next Flutter release in May, perhaps they will do one more beta before the cut-off for next stable release. I heard some rumors in that direction. I have no idea if it will be called Flutter 4.0 instead of 3.10 though, they might bump the major version since it should also include Dart 3.0, so it could make sense marketing wise Flutter 4/Dart 3. I'm just speculating here though.

esbozos commented 1 year ago

@rydmike Fortunately, I didn't get to compile or recreate when I saw your first reply, but it's good to have this reference on how to overcome coco pod issues.

By the way, Flutter 4/Dart 3 sounds appropriate and cool. Hopefully given that scenario, the developers will have that marketing idea revealed to them or read it around here.

rydmike commented 1 year ago

Released FlexColorScheme version 7.0.2 that can depend on material_color_utilities 0.2.0 on Flutter stable 3.7.x stable and material_color_utilities 0.3.0 on Flutter beta/master 3.10.0-x.

rydmike commented 1 year ago

@esbozos, for info, I opened issue #95 in the material-color-utilities repo, with the hopeful wish that it may lead to fewer of this type of issues in the future.