New API: dart:io.Platform.resolvedDartTool

[srawlins]

Developers sometimes rely on Platform.resolvedExecutable to find the "running" dart command on which a script is running. Then you can run, for example, Process.start(Platform.resolvedExecutable, ['pub', 'get']). This works when the running script is being run as JIT, with dart or dart.exe as the resolved executable.

But for a script which is compiled with AOT, Platform.resolvedExecutable resolves to dartaotruntime. And dartaotruntime pub get does not work. In order to compatibly use a dart binary, for example to run pub get, you can use the dart sibling to Platform.resolvedExecutable (or the dart.exe sibling).

It would be nice to expose this executable as a static getter on Platform. Maybe dartExecutable or dartTool (dart --help describes itself as a "utility". The website docs call dart "The Dart command-line tool".

Developers of analyzer plugins may need to be aware of this as analyzer is compiled AOT. See #50498.

[srawlins]

CC @a-siva

[a-siva]

//cc @lrhn

[lrhn]

That sounds like an "it depends".

If you do dart compile exe you can no longer assume that there is any Dart SDK available when the exe runs.

If you compile to an AoR snapshot, and run it with dartaotruntime, then presumably you have an SDK available, so you can find the SDK and the dart runtime three.

Which means that Platform is not the right place for it. The Platform is always there, the SDK might not be.

Consider instead having a helper library or package that can be used to find the Dart SDK, or it's features, and which only works (and may only compile) when run through an SDK.
(Make it be dart:sdk and make it not be there when AoT compiled to exe, or to JS, fx.)

The library can then interact with the runtime to find the SDK, which works when the runtime is from the SDK.

(This reminds me of a similar issue about finding the file path of the entry point script. That also only makes sense when you are running from source, or close to source, and not of you compile to exe.)