Accessing the package details seems to return invalid data.

[vlidholt]

I'm trying to access the name of the main package from Devtools running inside the browser. It looks like I'm getting invalid data back.

var rootInfo = serviceManager.rootInfoNow();

var package = rootInfo.package;
// Returns: "file:"

var library = rootInfo.library;
// Returns: "file:///Users/viktor/Projects/tests/gui_1/gui_1_server/bin/main.dart"

[kenzieschmoll]

What path would you be expecting for the "main package"?

[kenzieschmoll]

Here's an example of how we find the root path for a connected app in DevTools: https://github.com/flutter/devtools/blob/master/packages/devtools_app/lib/src/extensions/extension_service.dart/#L158.

This calls rootLibraryForMainIsolate, which you can copy to see if this works for you. To copy this, you'll have to fork https://github.com/flutter/devtools/blob/master/packages/devtools_app/lib/src/service/resolved_uri_manager.dart/ and just use serviceManager instead of serviceConnection.serviceManager in that file. The only other hacky thing you'll need to do to fork this and use it is to make sure ResolvedUriManager._packagePathMappings is initialized before you call any other methods on the class (normally this is initialized by calling ResolvedUrlManager.vmServiceOpened() as part of the service manager setup in DevTools).

If this solves your problem, we can add resolved_url_manager.dart to devtools_app_shared and move the resolvedUrlManager lifecycle logic from the main DevTools service manager to the lower level service manager that both DevTools and DevTools extensions use. Please let me know if you need any clarification on how to setup this workaround.

[vlidholt]

It's a bit unclear exactly what I would expect from:

serviceManager.rootInfoNow().package

But probably the name of the package (in my case gui_1_server). Returning file: seems incorrect.

I'm off for vacation for a few days now, but will try it out when I get back on Tuesday.

[kenzieschmoll]

@bkonyi it seems like we are assuming Isolate.rootLib.uri is a package URI based on the parsing logic here: https://github.com/flutter/devtools/blob/master/packages/devtools_app_shared/lib/src/service/isolate_state.dart/#L80.

Is this a bug? When can we expect LibraryRef.uri to be a package uri vs a file uri?

[bkonyi]

@bkonyi it seems like we are assuming Isolate.rootLib.uri is a package URI based on the parsing logic here: https://github.com/flutter/devtools/blob/master/packages/devtools_app_shared/lib/src/service/isolate_state.dart/#L80.

Is this a bug? When can we expect LibraryRef.uri to be a package uri vs a file uri?

There's definitely no guarantee that the root library will have a package URI from the VM's perspective. For example, dart foo.dart will likely have a root library URI of the form file:///User/foo/foo.dart.

As for when we report a package vs file URI, I'm not 100% sure as that's information provided to us by the CFE and not determined within the VM. However, I think it should be consistent for root libraries in Flutter applications (always package:// or always file://).

You can try to see if there's a package:// URI associated with the root library's URI by using the lookupPackageUris method on VmService, but I'm fairly certain that if LibraryRef.uri is a file:// URI then there isn't a package:// URI associated with it.

[kenzieschmoll]

If you upgrade your packages to the latest (devtools_app_shared: 0.0.8, devtools_extensions: 0.0.11) you will now have access to serviceManager.resolvedUriManager which may help what you are trying to do here.