Sdk: "Interpreting this as package URI" message is confusing

[Hixie]

I ran dart --enable-asserts lib/temp.dart and the output said (in addition to trying to run the program):

lib/temp.dart: Warning: Interpreting this as package URI, 'package:plexiglass/temp.dart'.

I have no idea what this means or why it says it.

[lrhn]

You are running lib/temp.dart. The full URI of that, based on current working directory, is file:///$cwd/lib/temp.dart. That is a file URI.
However, the library is inside a lib directory, so it can also be addressed as package:plexiglass/temp.dart. Since Dart uses the URI used to load a library as the identity of the libraries, those two ways to address the same file would become two different libraries.

More importantly, if the temp.dart file performs any import of a library in the same package using a relative URI reference, then it is resolved against the importing library's URI. So, if temp.dart has an import "plexiglass.dart";, then that would import that library as file:///$cwd/lib/plexiglass.dart, and not package:plexiglass/plexiglass.dart.

What would often happen is that some other library, perhaps even in a different package, would import package:plexiglass/plexiglass.dart using a package:-URI, and then you would have two different libraries. The types defined by those two libraries have no relation to each other, they just have the same name, and you will get odd type errors like Glass is not assignable to Glass. Yey. (This problem was smaller when all libraries had names, and you couldn't import two libraries with the same name into the same program. Alas, that was all library names were good for.)

In general, as a rule of thumb, you should never address a file inside a package's lib directory through a path containing lib. When you do that, you should instead use the package: URI. This includes when specifying a file on the command line.

Since nobody followed that rule, we made the parser recognize the issue and convert entry file file: URI to a package: URI when possible. We still warn you that we are changing your input.

To avoid the warning, do dart --packages=.packages --enable-asserts package:plexiglass/temp.dart instead.

[Hixie]

I don't think anyone cares about this though? I agree that interpreting the relative URL so as to avoid this problem is right, but it's not something the developer wants to even think about.

The current warning is entirely unactionable and uninteresting. If we really want people to jump through hoops and explicitly list the --packages even though it should be implicit, than we should say so in the warning. But that would make it even more obvious that the warning is pointless, IMHO.

Running relative paths is something we should support out of the box without fanfare.

[yjbanov]

I think Dart should stop relying on import URLs for library identity. I don't think we have a use-case for it any more. This is probably a leftover from the days when the VM was expected to be able to load and run libraries from the network. But that use-case is gone.

This is not the first time I'm encountering this:

• The first time I got confused
• An early Flutter issue
• Code in flutter_tools attempting to suppress it

[pedromassango]

Ok. I though there is something bad in my code. Any update on this?

[kwight]

I found this rather confusing too, trying to run a simple filewatcher on a simple testing directory – but it _did_ sort of explain why the CLI template from Stagehand runs its main from within bin (something else I didn't understand).

So basically, to get rid of the output while using the dart executable, run your main entry from anywhere _other_ than within the lib folder. (@pedromassango)

[Hixie]

I ran into this again (having forgotten about this bug), but this time I thought "oh, I guess what this means is that I should run dart package:foo/main.dart instead of dart lib/main.dart" but when I tried that Dart itself crashed with two 37-line stack traces:

Crash when compiling package:house_of_rooves_daemon/main.dart,
at character offset null:
FileSystemException(uri=package:house_of_rooves_daemon/.packages; message=StandardFileSystem only supports file:* and data:* URIs)
#0      StandardFileSystem.entityForUri (package:front_end/src/api_prototype/standard_file_system.dart:33:7)
#1      HttpAwareFileSystem.entityForUri (package:vm/http_filesystem.dart:16:23)
#2      HybridFileSystemEntity.delegate (package:front_end/src/fasta/hybrid_file_system.dart:47:37)
<asynchronous suspension>
#3      HybridFileSystemEntity.exists (package:front_end/src/fasta/hybrid_file_system.dart:51:41)
#4      ProcessedOptions._findPackages.checkInDir (package:front_end/src/base/processed_options.dart:563:52)
#5      ProcessedOptions._findPackages (package:front_end/src/base/processed_options.dart:568:37)
#6      ProcessedOptions._getPackages (package:front_end/src/base/processed_options.dart:498:30)
#7      ProcessedOptions.getUriTranslator (package:front_end/src/base/processed_options.dart:428:33)
<asynchronous suspension>
#8      generateKernelInternal.<anonymous closure> (package:front_end/src/kernel_generator_impl.dart:71:49)
#9      withCrashReporting (package:front_end/src/fasta/crash.dart:122:24)
#10     generateKernelInternal (package:front_end/src/kernel_generator_impl.dart:70:10)
#11     generateKernel.<anonymous closure> (package:front_end/src/kernel_generator_impl.dart:50:18)
#12     CompilerContext.runWithOptions.<anonymous closure> (package:front_end/src/fasta/compiler_context.dart:135:20)
<asynchronous suspension>
#13     CompilerContext.runInContext.<anonymous closure>.<anonymous closure> (package:front_end/src/fasta/compiler_context.dart:123:46)
#14     new Future.sync (dart:async/future.dart:224:31)
#15     CompilerContext.runInContext.<anonymous closure> (package:front_end/src/fasta/compiler_context.dart:123:19)
#16     _rootRun (dart:async/zone.dart:1126:13)
#17     _CustomZone.run (dart:async/zone.dart:1023:19)
#18     _runZoned (dart:async/zone.dart:1518:10)
#19     runZoned (dart:async/zone.dart:1465:12)
#20     CompilerContext.runInContext (package:front_end/src/fasta/compiler_context.dart:122:12)
#21     CompilerContext.runWithOptions (package:front_end/src/fasta/compiler_context.dart:133:10)
#22     generateKernel (package:front_end/src/kernel_generator_impl.dart:49:32)
#23     kernelForModule (package:front_end/src/api_prototype/kernel_generator.dart:99:17)
#24     SingleShotCompilerWrapper.compileInternal (org-dartlang-kernel-service:///pkg/vm/bin/kernel_service.dart:359:17)
#25     Compiler.compile.<anonymous closure> (org-dartlang-kernel-service:///pkg/vm/bin/kernel_service.dart:163:45)
#26     new Future.<anonymous closure> (dart:async/future.dart:176:37)
#27     _rootRun (dart:async/zone.dart:1122:38)
#28     _CustomZone.run (dart:async/zone.dart:1023:19)
#29     _CustomZone.runGuarded (dart:async/zone.dart:925:7)
#30     _CustomZone.bindCallbackGuarded.<anonymous closure> (dart:async/zone.dart:965:23)
#31     _rootRun (dart:async/zone.dart:1126:13)
#32     _CustomZone.run (dart:async/zone.dart:1023:19)
#33     _CustomZone.bindCallback.<anonymous closure> (dart:async/zone.dart:949:23)
#34     Timer._createTimer.<anonymous closure> (dart:async-patch/timer_patch.dart:23:15)
#35     _Timer._runTimers (dart:isolate-patch/timer_impl.dart:384:19)
#36     _Timer._handleMessage (dart:isolate-patch/timer_impl.dart:418:5)
#37     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:174:12)

Then I found this bug again and read the comment above about bin/main.dart so I tried that... and it didn't work either, because now relative paths don't work in a sane way.

I really don't see any value in this error message. Can we remove it?

[lrhn]

The reason dart package:foo/main.dart doesn't work is that it can't find .dart_tool/package_config.json relative to a package: URI, so you actually have to write

dart --packages=.dart_tool/package_config.json package:foo/main.dart

I'm perfectly aware that this is not something we can make people do. That's why we recommend not having "main" files inside lib/. The bin/ directory is the traditional place to put entry points.
If you all it foo.dart instead of main.dart and put it in bin/, you can even do pub run foo.

[Hixie]

@lrhn Can you explain to me the value of the warning here? Why does it matter if someone runs dart lib/foo.dart? Why do we want to encourage running Dart programs through the pub tool instead of the dart tool? Why do we care if they have a bin/ directory and split their code across multiple directories instead of just having a single place? Why do we care what it's called? (I'm not saying we shouldn't, I just don't have any answers to any of these questions.)

[shinriyo]

Android Studio?
I upgrade Android Studio, it happened...