Provide a way of getting packageRoot as a Uri

[johnniwinther]

Platform.packageRoot should return a Uri.

Currently is is passed on verbatim from the system, and even though the package root always refers to a directory-like resource every user must ensure that it is normalized before handling.

For instance, you cannot use

Uri packageRoot = Uri.base.resolve(Platform.packageRoot);

because it might be missing a trailing slash and might contain ''.

[kevmoo]

We can't change the type returned from packageRoot – we want to avoid breaking changes.

We could add a packageRootUri property or similar, though

---

Added Library-IO label.

[andersjohnsen]

Consider using 'new Uri.file(Platform.packageRoot)' to get the Uri you need. You will still need to look for tailing slash though.

[johnniwinther]

For a Platform-independent version without double slashes that would require:

Uri fileUri = Uri.base.resolveUri(
    new Uri.file(Platform.packageRoot, windows: Platform.isWindows));
Uri dirUri = fileUri.path.endWith('/') ? fileUri
    : new Uri(scheme: fileUri.scheme, path: '${fileUri.path}/');

This is, and will be, handled incorrectly in many use-cases.

[andersjohnsen]

  Uri fileUri = Uri.base.resolveUri(new Uri.file(Platform.packageRoot));
  Uri dirUri = fileUri.path.endWith('/') ? fileUri
      : new Uri(scheme: fileUri.scheme, path: '${fileUri.path}/');

Should be sufficient.

But I agree, it's non-trivial.

[sethladd]

cc @iposva-google

[sethladd]

For those following along, this getter will start to return a URI if the VM has resolved packageRoot, even if --package-root was not set on the command line. In other words, if the VM has decided to use a package root, then packageRoot will return something.

[johnniwinther]

That might even be worse. If you want to create a new process in your own package environment you will not be able to do so if you don't rely on packages yourself.

[iposva-google]

Johnni, I am not sure what you are trying to say in your last comment. But let me explain the semantics that Seth has been referring to:

• If the dart standalone binary is started both with a --package-root and --packages flag then this is an error and launch will be aborted.
• If the dart standalone binary is started with --package-root=<some/uri> then you will end up with a result which points you at the fully resolved URI of the command line argument. This URI is also used to load all packages.
• If the dart standalone binary is started with a --packages=<some/uri> then the result is a null packageRoot, since this isolate is not using a package root to load packages.
• If the dart standalone binary was started with neither a --package-root or --packages flag then the location of a .packages file or packages/ directory according to the packages spec. If the resolution of that operation found a packages/ directory next to the main script, without finding a .packages file next to the main script, then you get the fully resolved URI of that packages/ directory or null if a .packages file was found or no packages/ directory was found. (The rules about http based scripts vary slightly in this case, please see the packages spec.)

The above points are evaluated in the order they have been listed for the root isolate. For spawned isolates the parameters to spawnUri are equivalent to command line flags. In all cases the result is irrespective of whether your isolate has or has not loaded any packages.

[johnniwinther]

Sounds good.

[mit-mit]

@iposva-google, you are working on this, right?

[iposva-google]

Correct. A CL (https://codereview.chromium.org/1334353002/) is in review, but a lot of tests need adjusting...

[mit-mit]

Landed: https://codereview.chromium.org/1334353002/

[nex3]

This has been rolled back, so I'm re-opening.

[mit-mit]

And I believe it has been landed again, so closing