fluttercommunity package_info_plus - version.json

[Markus43]

Packages like package_info_plus provide ways to read the name and version of an app programmatically within flutter apps. This doesn't work with custom embedders unfortunately: flutter "bundle" builds simply do not contain these infos in a parsable way. On linux gtk builds, this info is available in a file version.json directly in the flutter_assets folder.

Typical content:

{"app_name":"my_app","version":"1.2.3","build_number":"42","package_name":"my_app"}

Would it maybe make sense to generate the same file with flutter app builds in this recipe?

According to the reply I got on custom embedders discord, this is currently expected to be generated by the tooling that belongs to the embedder ...

[jwinarske]

I was looking at this yesterday. package_info_plus requires this file. In the case of the Linux variant it doesn't use the platform interface, and it expects the file to be found relative to the embedder; which is not the case. This is kind of quirky in the first place.

[Markus43]

... This is kind of quirky in the first place.

Yes it is. I don't understand why they don't just put this information in a build environment variable and wrap it with a String.fromEnvironment in some k*** constant so it can be accessed where necessary. On Windows. they put it in the .exe, and package_info_plus extracts it back from the exe.

Probably for meta-flutter it would be best to just put such things in a dart-define, e.g. meta_flutter.appVersion, so they can just be parsed like that.

[jwinarske]

Ultimately it would be best if it were a federated plugin. Then we could easily override the behavior. This is what I like about the first party stuff. I supposed two options:

1. Fork the plugins (too much overhead to manage)
2. Upstream a better design

I'm finding quite a few plugins that could use a re-work. Conversion to federated, and pigeon where it makes sense.

There really should be a standard way of returning the flutter_asset directory to a plugin. Perhaps it's seen as a security risk, not sure why it was omitted in the registrar.

In the case of the linux variant of package_info_plus it avoids the platform channel call, so it's a cheap call.

[jwinarske]

I just dialoged with Chinmay. He is indicating that if flutter_assets is mapped as an asset_manager (engine side) you can just use relative paths in Dart, and it will iterate all asset_managers until it finds a match. So the approach in the Linux Dart code for package_info_plus could simply load version.json, opposed to "finding the executable approach". Not sure if that's in the Linux embedder tree, but mapping the flutter_assets folder to an asset_manager really should be added. If it's already there it would be an easy Dart change. I know I've had to work around this in other cases, and this would resolve my work arounds. This would be a good patch to carry for flutter-engine.

[jwinarske]

So three parts to address this:

1. https://github.com/fluttercommunity/plus_plugins/pull/2617
2. https://github.com/meta-flutter/meta-flutter/issues/431
3. Generate version.json. Which would be dependent on the app. I would add this as a dedicated recipe, installing to the desired flutter_assets folder.

[jwinarske]

Turns out I was premature on the PR (1). After cleaning the build and re-running it appears there is not a default asset manager for Linux GTK. So I need to submit an Engine PR.