Notify about existing caches when preloading

[sigurdm]

Check if there are existing user caches when Flutter is first time accessing the pub cache after extracting the downloaded archive.

If they exist we give instructions how to reset/repair these caches.

[sigurdm]

See internal doc: go/dart-flutter-pub-alignment for design/details

[christopherfujino]

LGTM

[christopherfujino]

Actually, I wonder if this will break flutter run --machine. This is what I get when I run flutter run -d linux --machine 2>/dev/null

$ flutter run -d linux --machine 2>/dev/null
Found an existing Pub cache at /home/fujino/.pub-cache.
It can be repaired by running `dart pub cache repair`.
It can be reset by running `dart pub cache clear`.
Found an existing Dart Analysis Server cache at /home/fujino/.dartServer.
It can be reset by deleting /home/fujino/.dartServer.
Resolving dependencies...
  async 2.10.0 (2.11.0 available)
  material_color_utilities 0.2.0 (0.3.0 available)
Got dependencies!
[{"event":"daemon.connected","params":{"version":"0.6.1","pid":834968}}]
[{"event":"app.start","params":{"appId":"2eb0dd8d-adc6-472c-8677-445e19fe35a6","deviceId":"linux","directory":"/home/fujino/git/tmp/delete_me_flutter_box","supportsRestart":true,"launchMode":"run"}}]
Launching lib/main.dart on Linux in debug mode...
[{"event":"app.progress","params":{"appId":"2eb0dd8d-adc6-472c-8677-445e19fe35a6","id":"0","progressId":null,"message":"Building Linux application...","finished":false}}]
[{"event":"app.progress","params":{"appId":"2eb0dd8d-adc6-472c-8677-445e19fe35a6","id":"0","progressId":null,"finished":true}}]
[{"event":"app.stop","params":{"appId":"2eb0dd8d-adc6-472c-8677-445e19fe35a6"}}]

@DanTup is this going to break you?

[DanTup]

@DanTup is this going to break you?

Assuming what we're talking about here is just extra (non-JSON) stdout content, I don't think so. flutter run --machine already prints a fair bit of non-JSON output (like "Launching lib/main.dart on Linux in debug mode...") so consumers of it already have to handle it (generally anything that doesn't parse as a JSON list just goes straight to the Debug Console).

It's not great that it works this way - if a user prints well-formed JSON from their flutter app, we will try to interpret it as an event from the Flutter daemon. It would be better if all output was wrapped in the JSON protocol, but I think some of it ("Building flutter tool") can come from the shell script so it may be more trouble than it's worth.

[christopherfujino]

@DanTup is this going to break you?

Assuming what we're talking about here is just extra (non-JSON) stdout content, I don't think so. flutter run --machine already prints a fair bit of non-JSON output (like "Launching lib/main.dart on Linux in debug mode...") so consumers of it already have to handle it (generally anything that doesn't parse as a JSON list just goes straight to the Debug Console).

It's not great that it works this way - if a user prints well-formed JSON from their flutter app, we will try to interpret it as an event from the Flutter daemon. It would be better if all output was wrapped in the JSON protocol, but I think some of it ("Building flutter tool") can come from the shell script so it may be more trouble than it's worth.

Ahh, good to know how this works. I'll file a tracking issue for this, but you're right, we'll probably never be 100% JSON, because I'm not interested in parsing all CLI flags from bash :P

[christopherfujino]

LGTM