dart standalone embedder produces error messages when copied/run outside of dart-sdk

[aam]

PS C:\src\t1> copy C:\src\d\dart-sdk\sdk\out\ReleaseX64\dart.exe .
PS C:\src\t1>
PS C:\src\t1> .\dart
Failed to start the Dart CLI isolate. Could not resolve DartDev snapshot or kernel.
(null).
PS C:\src\t1> .\dart --help
Failed to start the Dart CLI isolate. Could not resolve DartDev snapshot or kernel.
(null).

Note that script execution works

PS C:\src\t1> .\dart C:\src\d\dart-sdk\sdk\hostname.dart
aam0

Printing help message works too as long as you specified '--help' and '--verbose'

PS C:\src\t1> .\dart --verbose  --help
Usage: dart [<vm-flags>] <dart-script-file> [<script-arguments>]

Executes the Dart script <dart-script-file> with the given list of <script-arguments>.

Supported options:
--enable-asserts
  Enable assert statements.
--help or -h
  Display this message (add -v or --verbose for information about
  all VM options).
--packages=<path>
  Where to find a package spec file.
--define=<key>=<value> or -D<key>=<value>
  Define an environment declaration. To specify multiple declarations,
  use multiple instances of this option.
--observe[=<port>[/<bind-address>]]
  The observe flag is a convenience flag used to run a program with a
  set of options which are often useful for debugging under Observatory.
...

cc @bkonyi @rmacnak-google

[bkonyi]

This is WAI. The standalone VM isn't meant to be run outside of the context of the SDK as the CLI isolate requires access to both $DART_SDK/bin/snapshots/dartdev.dart.snapshot and $DART_SDK/bin/snapshots/dds.dart.snapshot to provide the needed support for developer tooling.

[aam]

At a minimum I feel we should provide better error message. Also, the fact that dart --verbose --help and dart <scriptname> work, begs the question of what is so critical in missing artifacts(dartdev.dart.snapshot, dds.dart.snapshot, etc), so that dart without arguments or dart --help fail to work.

[bkonyi]

I'm all for improving the error message (do you have any preference? :-)), but these artifacts are definitely critical if you want to do anything more than run a Dart program from source.

dart --help will fail as it's no longer meant to provide the help message for the VM but the entire suite of Dart development tools:

$ dart --help
A command-line utility for Dart development.

Usage: dart <command|dart-file> [arguments]

Global options:
-v, --verbose               Show additional command output.
    --version               Print the Dart SDK version.
    --enable-analytics      Enable analytics.
    --disable-analytics     Disable analytics.
    --suppress-analytics    Disallow analytics for this `dart *` run without changing the analytics configuration.
-h, --help                  Print this usage information.

Available commands:
  analyze    Analyze Dart code in a directory.
  compile    Compile Dart to various formats.
  create     Create a new Dart project.
  devtools   Open DevTools (optionally connecting to an existing application).
  doc        Generate API documentation for Dart projects.
  fix        Apply automated fixes to Dart source code.
  format     Idiomatically format Dart source code.
  info       Show diagnostic information about the installed tooling.
  pub        Work with packages.
  run        Run a Dart program.
  test       Run tests for a project.

Run "dart help <command>" for more information about a command.
See https://dart.dev/tools/dart-tool for detailed documentation.

dart without arguments is interpreted as dart --help, as it always has been.

The dart <scriptname> and dart --help --verbose are special cases, mostly for use by the Dart team. dart <scriptname> is an escape hatch that avoids calling into the CLI isolate to save a few milliseconds in the case where a user simply wants to run a Dart program without any debugging support. dart --help --verbose is there for legacy purposes as the CLI isolate isn't aware of all the advanced flags provided by the VM and it would be non-trival to make the CLI isolate aware of them.

We've long been at the point where the VM and tooling assumes that both these artifacts are available for Dart development workflows. For example, dart --observe foo.dart will fail with a similar message since DDS is spawned by the CLI isolate and DevTools is served by DDS.

Unfortunately, you just happened across the two scenarios where the standalone VM works outside of the context of the Dart SDK. We don't make any guarantee about the VM's behavior outside of the SDK, and users copying the VM executable outside of the SDK are taking risks doing so.

[a-siva]

I'm all for improving the error message (do you have any preference? :-)), but these artifacts are definitely critical if you want to do anything more than run a Dart program from source.

Maybe it is best to state that the Dart executable is being run from outside of the context of a Dart SDK and the behaviour is undefined.

[bkonyi]

That sounds reasonable. Should we also consider moving this check earlier in the startup sequence so dart <scriptname> and dart --help --verbose produce the same error if dart isn't in the right location?

[a-siva]

That sounds reasonable. Should we also consider moving this check earlier in the startup sequence so dart <scriptname> and dart --help --verbose produce the same error if dart isn't in the right location?

Are you proposing we produce the error and bail out or we print the error and continue doing what we do today? The later might work better.

[bkonyi]

I was thinking produce the error and bail out. I'd rather fail hard if we're running in an unsupported environment than print an error and continue as normal, only to cause confusion in the future when we change some implementation details in the VM that would make one of these two special cases no longer work.