-
Notifications
You must be signed in to change notification settings - Fork 228
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a way to find the package_config.json
file for a given pubspec.yaml
file
#4218
Comments
Good point. The rule is:
Not sure where we best place to share this logic. Perhaps https://pub.dev/packages/pubspec_parse... or https://pub.dev/packages/package_config. Alternatively we need a way to ensure resolution of current location is resolved and has an up-to-date package_config.json. |
I might be missing something. I'm not sure why other tools need to read If you are a Dart toolAn outline of what a Dart tool can do, at the risk of being slightly off topic 🙈 If you are a Dart tool. You can:
As a Dart tool you cannot:
This is just not available in Ability to inspect the dependency-graph might be useful for something like Dart tooling in
|
I think I agree with Jonas' comment. But I'd like you to expand on your use case. We might not really understand what you are trying to do. |
Some additional pieces of context:
Unrelated to this issue, but I am very much in favor of this too 😄 this would allow us to distinguish between DevTools extensions provided by direct and transitive dependencies. We likely want to ignore extensions from transitive deps by default.
Yes this is correct. Imagine a user opens To do this, we look for the package root of the connected application. This logic does the following for a running app:
Once we have this "root", we build the URI to the |
It seems to me that "Dart Tooling Daemon" is not supposed to read files outside the IDE workspace root. But with pub workspaces Should we transfer this issue to the sdk - as this is a "Dart Tooling Daemon" feature request? |
Can you elaborate on what you mean by "pub-workspace"? I don't think DTD should have special logic to "find the package config", as this would likely require DTD to walk the directory structure beyond its restrictions. These are not technical restrictions of DTD, but intentionally placed security restrictions on DTD. What does the "workspace" section in a pubspec.yaml file look like? Does this contain the path to the |
I'm working on flutter.dev/go/pub-workspace With this proposal the .dart_tool/package_config.json can be placed above the root level of a package if it is a member of a workspace. If the IDE is opened with that package only, then we need some kind of escape hatch to reach the package config (or DTD will allow access to the entire workspace, not only the "focused" package. |
How would pub find the
Could pub expose a command |
Pub (and other dart processes) has access to the whole file system, not only from the IDE root. |
Great! What do you think then about exposing a command that the Dart Tooling Daemon, which is limited to the scope of the IDE workspace, could use? |
Or another idea would be to modify or add a new API to |
I don't think the tooling daemon is limited in what it can access, I rather think it itself imposes limits on what it allows its client to access. This restriction is imposed here: https://github.com/dart-lang/sdk/blob/ba8306735d7efa8aabfbf4d8f9a618bd00bfbcbd/pkg/dtd_impl/lib/src/service/file_system_service.dart#L204 And I believe we could special-case that limit somehow to allow accessing the .dart_tool/package_config.json (or perhaps allow accessing the entire workspace instead of only the IDE part). |
This is correct. Because third party tools can connect to DTD, we need to limit what parts of the file system can be read from / written to.
This may be acceptable. @bkonyi and @CoderDake what are your thoughts? I do still think extending
This would concern me that we could end up walking all the way up the tree if the |
With upcoming monorepo support, we can no longer assume that the
package_config.json
file lives in the same package root as thepubspec.yaml
file:In a monorepo, the
package_config.json
file may live further up in the directory structure.For some development tools (DevTools extensions, other features powered by the Dart Tooling Daemon) we need to know both where the
pubspec.yaml
files are in an IDE workspace and where the pub solve for eachpubspec.yaml
file lives. Due to some constraints with file access, we can't walk up the tree until we find the firstpackage_config.json
file, as this file may not even be in the user's IDE workspace.Ideally, we should have an API or some shared package that we can use to find the expected location of the
package_config.json
for a givenpubspec.yaml
file.CC @jonasfj @sigurdm @bkonyi @CoderDake
The text was updated successfully, but these errors were encountered: