package-root bug in the vm: import a file with a 'package:' and a relative URL

[sigmundch]

When importing a file with 'package:' the file should resolve to the same library as if it was imported with a relative URL. This is similar to issue #3147, but in the vm.

Example to repro this error:
./out/Release_ia32/dart --package-root=./ a.dart

Where a.dart is:

library("a");

import('b.dart', prefix: 'b1');

import('b.dart', prefix: 'b2');

import('package:b.dart', prefix: 'b3');

main() {
  print("${b1.x === b2.x} ${b1.x === b3.x}");
}

And b.dart is:

library("b");

class X {
  const X();
}

[sigmundch]

On that example: the program should print "true true", but prints "true false"

[iposva-google]

I think you are misunderstanding how URLs are handled. Assuming that a.dart is in the /home/sigmund/dart/app1 directory then the script is loaded from "file:///home/sigmund/dart/app1/a.dart", which means that resolving the relative URI "b.dart" from within that script loads "file:///home/sigmund/dart/app1/b.dart", which is demonstrably not equal to "package:b.dart" even if they end up loading the same file.

Similar rules exist when the browser loads resources from "file:///somepath" vs. "http://127.0.0.1/somepath" vs. "https://sigmunds_machine/somepath".

---

Added AsDesigned label.

[peter-ahe-google]

Hi Siggi,

I think the VM handles this correctly. You must take care to load the script correctly. If you give a relative URI on the command line, the VM should create this URI for the script:

new Uri.fromString("file://${new File('.').fullPathSync()}/a.dart");

As Ivan says, this would be something like "file:///home/sigmund/dart/app1/a.dart".

If you give the VM an absolute URI, for example, package:a.dart, it handles this program as you expect:

$ ./xcodebuild/Release_ia32/dart --package-root=./ package:a.dart
true true
$

This is important as this allows moving a directory hierarchy to the package directory without having to rewrite relative URIs in the directory.

To understand why you have to specify the package URI on the command line, consider how URI resolution works. The example contains two URIs, "b.dart" and "package:b.dart". Each of these must be resolved according to a base URI (that is the URI of the current compilation unit).

new Uri.fromString("file:///home/sigmund/dart/app1/a.dart").resolve("b.dart") is "file:///home/sigmund/dart/app1/b.dart".

new Uri.fromString("file:///home/sigmund/dart/app1/a.dart").resolve("package:b.dart") is "package:b.dart".

BUT

new Uri.fromString("package:a.dart").resolve("b.dart") is "package:b.dart".

new Uri.fromString("package:a.dart").resolve("package:b.dart") is "package:b.dart".

You can read about how this works here: http://tools.ietf.org/html/rfc3986#section-5

In those terms, the VM uses a "Default Base URI" of file://CURRENT_DIRECTORY/ for resolving the URI on the command line, and that then defines the "Base URI from the Retrieval URI" for resolving URIs in #import and #source tags.

Cheers,
Peter

[sigmundch]

Thanks for the clarification!

I also over simplified my example. I really care about the situation you describe (running 'package:a.dart') or equivalently if I add a third file 'c.dart' with this contents:

#library('c');
#import('package:a.dart');

Then I expect to have 'true true' when I call
./out/Release_ia32/dart --package-root=./ c.dart

This is working as intended in the VM, seems broken in frog (I'll update that bug).