[native_assets_cli] fetch and offline mode

[dcharkes]

@reidbaker Suggested we should have fetch hook/flag, and an offline flag.

I've spend some thought on what would be a good way of doing this.

One design goal should be that a build hook can wrap an existing native build system or native package manager. This leads to the following design constraints:

• The directory between fetch and build should be shared. Otherwise the fetch step invoking the fetch step in the native tool would download dependencies to a place where the build step cannot access them.

Another design goal should be that after the fetch step, the build step wouldn't need any internet access. In other words, it would succeed offline. This leads to the following design constraints:

• The fetch step needs the same configuration as the build step. This includes build mode, link mode preference, OS, architecture, minimum API versions for NDK/iOS/MacOS. Any of these configuration parts could lead to different assets as output. If libraries are prebuilt and downloaded in the fetch step, they fetch step needs to know these configuration options.
  • (As a side note, this means an implementation for Flutter for invoking the fetch step would require roundtripping through the Flutter app Gradle/XCodeProject to get some of this info. flutter run doesn't have target architectures available for example, only flutter assemble does.)

I'm not sure if the best design would be to have a hook/fetch.dart which would get a FetchConfig (most likely no output, just exitCode of the process for success or not). Or if BuildConfig should get a bool fetchOnly.

Pros for fetch as flag on hook/build.dart

• If fetchOnly is false, it's a single process invocation for fetch and build, instead of two.
• Hook writers that use helper packages for a native build system, can simply forward to a helper package which will do the right thing (package:gradle), fetch on fetch, build on build, offline on offline. If we have a hook/fetch.dart and a hook/build.dart there'd be two hooks which forward with the same configuration.
• It's 100% obvious that fetch and build hooks have access to the same configuration, and the same output directory.

Cons for fetch as flag on hook/build.dart

• It's less explicitly split.

For offline, I think a bool on BuildConfig is the right place.

And offline and fetch are related in the sense that after fetch the build hook should not need any internet access. Which passing the offline flag would enforce.

@HosseinYousefi @mosuem @liamappelbe @brianquinlan In your use cases, do you wrap existing native build systems / native package managers that need internet access to fetch dependencies? (To produce dylibs/jars/...) And if yes, do those have a separate fetch step and an offline mode?

Any other concerns we should take into account for a fetch step/flag and offline flag?

cc @mkustermann @stuartmorgan

[mosuem]

To be had in a separate discussion probably:

If fetchOnly is false, it's a single process invocation for fetch and build, instead of two.

That we do many process invocations for hooks is a problem in itself, which I believe should be addressed at some point (Maybe collect all hooks into a single Dart file?).

[brianquinlan]

In your use cases, do you wrap existing native build systems / native package managers that need internet access to fetch dependencies? (To produce dylibs/jars/...) And if yes, do those have a separate fetch step and an offline mode?

Not in any use case that I've encountered so far.