-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Redact absolute root module file path in MODULE.bazel.lock
#18949
Closed
+171
−22
Closed
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you for the fix, but I was thinking that we could just actually use the label in error messages too (i.e. change the logic in ModuleFileFunction). IMO it's pretty clear which file
@@//:MODULE.bazel
(or better, if we useLabel#getDisplayForm()
,//:MODULE.bazel
) is referring to. That would also remove this special-casing at lockfile read/write time. WDYT?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that absolute paths still provide the best usability here: You can often just copy&paste the path together with the line number to go to the correct place in your editor. All other Starlark stack traces also contain absolute paths in this place. Building
//:MODULE.bazel
or querying for it also results in an error about the file not being exported.I view the switch to labels as a tradeoff that reduces implementation complexity at the cost of usability. This is definitely warranted for non-registry overrides, which are a bit more of an "advanced" concept anyway. But if we can keep absolute paths for the root module file, which I expect to cause most errors arising in practice, with a reasonable amount of complexity, then we should consider doing that.
I am actually not sure anymore whether the display form is better for non-root modules: The canonical form has the advantage that it more directly corresponds to the
external
path on disk, which is ultimately what the user wants to find if they face an error.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To be clear, is your preference to use labels for non-registry overrides in error messages?
I don't really mind it either way. The difference would only be
@foo//:MODULE.bazel
vs@@foo~override//:MODULE.bazel
, which is not a huge deal IMO.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally we would also keep absolute paths for them. But I can see how that would introduce too much complexity (tracking and replacing the output base) for too little gain (non-registry overrides were explicitly added by the user, so they should have a better idea where their module files live). That's why I consider labels a decent tradeoff in this case.
Couldn't it be
@my_gazelle//:MODULE.bazel
vs@@gazelle~override//:MODULE.bazel
? In that case, the former could make it harder to locate the directory inexternal
. But of course it's also more easily recognized by the user, so I'm not completely sure which I like better.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alright. This is holding up 6.3.0, and while I'm not a huge fan of the special de/serialization logic, I don't have a better idea right now. So let's get this submitted (and I'll fast track the label fix for non-registry overrides). Thanks!