-
Notifications
You must be signed in to change notification settings - Fork 385
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
Don't hard fail if there's a second request to bazelize the same Go module #1949
base: master
Are you sure you want to change the base?
Changes from 4 commits
7df94f2
9ca14e9
acb6e24
cd77474
b9a7f7b
c94aca1
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -119,6 +119,17 @@ def with_replaced_or_new_fields(_struct, **replacements): | |
|
||
return struct(**new_struct_assignments) | ||
|
||
def repo_name(importpath): | ||
path_segments = importpath.split("/") | ||
segments = reversed(path_segments[0].split(".")) + path_segments[1:] | ||
candidate_name = "_".join(segments).replace("-", "_") | ||
|
||
def _encode_case(c): | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. changing the encoding isn't a bad idea, but I do worry that this encoding itself could cause more conflicts. Is there a more conflict resistant encoding? Also, I believe any encoding change would require both the extension and gazelle BUILD.bazel generation to be in proper sync. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not super convinced yet that supportive case sensitivity is the right call – obviously open to convincing, but sharing my current gut-feeling. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @stefanpenner @fmeum It looks like the behavior for modules pulled in via
->
Should we use the same encoding? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ! isn't valid in repo names though. |
||
"""Repo names end up as directory names, therefore we can't rely on case to distinguish importpaths that only differ in case""" | ||
return "_" + c.lower() if c.isupper() else c | ||
|
||
return "".join([_encode_case(c) if c.isalnum() else "_" for c in candidate_name.elems()]) | ||
|
||
def extension_metadata( | ||
module_ctx, | ||
*, | ||
|
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.
This is a dict keyed by path, so I'm surprised to see duplicated modules. Could you share what
path
andmodule
look like for a colliding pair?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'm also curious, would it be possible to add the failing scenario to the existing test suite?
I would like to be sure that we aren't masking a upstream problem
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 see this is the scenario, do you think it would be possible to add it to something like https://github.com/bazelbuild/bazel-gazelle/blob/master/tests/bcr/go_mod/go.mod
Maybe @fmeum has a better idea to ensure we prevent regression
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.
Sure, this is the full error message:
In one of my
go.mod
(s), I see:and
Output of go mod why:
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.
path
:github.com/shurcooL/githubv4
module
:struct(local_path = None, raw_version = "0.0.0-20230424031643-6cea62ecd5a9", repo_name = "com_github_shurcool_githubv4", to_path = None, version = ((("", 0), ("", 0), ("", 0)), (("20230424031643-6cea62ecd5a9",),)))
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.
Could you just update all your imports to use
github.com/shurcooL/githubv4
?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.
@linzhp Thanks for chiming in and yes, that does work for our specific use case. However in the future it's possible that this won't be an option and it's ideal to solve this for the generic use case.
If the solution is simply that Gazelle won't distinguish modules that only differ in case, then it's best to document that explicitly here. Currently, the extension just fails because it won't create duplicate
go_repository
rules.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.
Could you update this PR to instead fail with a clean error message mentioning the two colliding names and explaining that module names that differ only in casing and punctuation are not supported (yet)?
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.
Certainly @fmeum
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.
#1954 @fmeum