Build: `package:flutter` resolution in `built_value`

[davidmorgan]

I think the latest release was intended to help with

https://github.com/google/built_value.dart/issues/513

--did I understand correctly?

Thanks!

[jakemac53]

Correct, that should work now.

This is based on the build_resolvers version however not the build version, you will need version 1.2.1.

[jakemac53]

Re-opening this, after following up in the other issue I was able to reproduce with flutter version 1.9.1+hotfix6 and this pubspec.lock file which has the expected versions of build_* packages.

[jakemac53]

OK, I have tracked down the root issue here. The problem is that Platform.version for Flutter 1.9.1 (and probably previous versions) looks just like a normal Dart SDK version (specifically, 2.5.0 (Fri Sep 6 20:10:36 2019 +0200) on "linux_x64").

We detect flutter by searching for the word flutter in this version string, which apparently was not introduced until flutter version 1.10.0.

I don't know of a better way to detect whether we are running in flutter or not, @jonahwilliams are you aware of anything more robust on older flutter versions?

I am reluctant to add anything to hacky given that this does work on the latest stable flutter releases.

[MrCreeper1008]

Not sure if I am adding anything here, but is it possible to detect Flutter with where flutter or something like that? Or am I missing anything here?

[jakemac53]

There isn't an obvious built in way to detect flutter other than the version string.

However, I spoke with some colleagues and we came up with a solution that will work (and be more robust than the current version string check going forward as well). We can use conditional imports to create our own boolean which is set based on the presence of dart:ui or not.

[jakemac53]

It looks like we should also do a patch release for 1.2.1+1 since the newest build_resolvers requires the latest analyzer which isn't possible to get yet (at least not with built_value)

[jakemac53]

Actually nevermind that fix doesn't work because the resolver is actually running in the command line Dart VM so dart:ui does not exist :sob: .

[jakemac53]

@MrCreeper1008 is updating to flutter 1.10.0 or later an option for you?

[MrCreeper1008]

Yes; should i upgrade?

[jakemac53]

Yes, I think given the current constraints we will probably not attempt to backport anything for older flutter sdks given that this does work with the current stable release and there isn't any non-hacky way of supporting the older ones (we would essentially have to dig around the file system structure and look for specific artifacts).

The easier solution is to just upgrade your flutter version, assuming that is reasonably possible to do. If there is some blocker to users upgrading we may reconsider though.

[MrCreeper1008]

Makes sense. I'll try upgrading and see if the issue persists. Thanks!

[MrCreeper1008]

Didn't realize1.10 is a beta release...need to hold off until its stable first.

[jakemac53]

Oh - I didn't realize that either the version tags are confusing I guess.

We may consider some sort of file system spelunking hack then.

[fibbers]

I was also running into problems using built_value with Color from dart:ui and tried several Flutter versions with a minimal project. I was interested in the Dart version as well, because of compatibilities with packages I use.
Here are the results I found, hope it helps someone searching for a compatible version:

| Flutter version | Dart tools version (from flutter --version) | result|
|---------------|-------------|-------|
| 1.10.0 | Dart 2.5.0 (build 2.5.0-dev.4.0 36985859e4) | ✅ |
| 1.10.7 | Dart 2.6.0 (build 2.6.0-dev.0.0 1103600280) | ✅ |
| 1.10.8 | Dart 2.6.0 (build 2.6.0-dev.0.0 98b286de21) | ✅ |
| 1.10.15 | Dart 2.6.0 (build 2.6.0-dev.8.2 bbe2ac28c9) | ✅ |
| 1.10.16 | Dart 2.7.0 | ❌ |
| 1.11.0 | Dart 2.7.0 | ❌ |
| 1.12.13+hotfix.3 | Dart 2.7.0 | ❌ |
| 1.13.0 | Dart 2.7.0 (build 2.7.0-dev.2.1 a4d799c402) | ✅ |

[shyndman]

Hi there. This is impacting users of MobX, and I wanted to see if I could lend a hand.

As an alternative approach, could we check the project's .packages or packages.json for a flutter reference, and use that as the condition?

That, along with the existence of p.join(p.dirname(dartSdkPath), 'pkg', 'sky_engine', 'lib'), seems like a pretty strong signal.

Pretty low impact too, I think. The one change that might be required is invalidating the .sum if Flutter is _added_ at some point. Removal of Flutter could probably be ignored.

[jakemac53]

Definitely open to a PR for this.

We need to ensure the user is actually running with the flutter sdk and not the dart sdk - whether or not they have a flutter dependency in their package could be used as a signal that they _should_ be running with the flutter sdk but not that they _are_ running with the flutter sdk, if that makes sense.

For that reason I think a file spelunking solution is probably best, possibly in combination with some warning if we see a flutter dependency but don't recognize your sdk as the flutter sdk.

I don't know what files would be relatively consistent to search for either, if we think bin/cache/pkg/sky_engine is good then I am fine with that. Do we know what version that was added in?

Pretty low impact too, I think. The one change that might be required is invalidating the .sum if Flutter is _added_ at some point. Removal of Flutter could probably be ignored.

We have to invalidate if the SDK ever changes anyways - so as long as we are basing this on the SDK you are using and not what you depend on then this should just work.

[jonahwilliams]

sky_engine has been there for a long time, longer than I've been on the team. We could also set some sort of environment variable or pass some flag through when run through flutter pub if that makes it easier

[jakemac53]

sky_engine has been there for a long time, longer than I've been on the team.

Sounds good then

We could also set some sort of environment variable or pass some flag through when run through flutter pub if that makes it easier

This won't help unfortunately because the purpose here is to detect the flutter sdk on old versions. Newer versions (at least the last time I looked at this) expose the flutter version in the Platform.version string so we are detecting that (and should probably continue to do so?).

Unless you think longer term the environment variable will be more robust than inspecting the version string.

[shyndman]

Great. So it sounds like sky_engine is a good test for now.

Definitely open to a PR for this.

Still the case? I'd be happy to write something up.

[jakemac53]

Still the case? I'd be happy to write something up.

yep!