Skip to content

Conversation

@fmeum
Copy link
Collaborator

@fmeum fmeum commented Mar 29, 2023

Allows module extensions to determine whether a given tag represents a dev dependency.

Fixes #17101
Work towards #17908

Allows module extensions to determine whether a given tag represents a
dev dependency.

Fixes bazelbuild#17101
Work towards bazelbuild#17908
@fmeum fmeum force-pushed the is-dev-dependency branch from ad59144 to a18f6cc Compare March 29, 2023 07:50
@fmeum fmeum marked this pull request as ready for review March 29, 2023 07:50
@github-actions github-actions bot added awaiting-review PR is awaiting review from an assigned reviewer team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. labels Mar 29, 2023
if (proxy.extensionBzlFile.equals(extensionBzlFile)
&& proxy.extensionName.equals(extensionName)) {
return proxy;
return proxy.withDevDependency(devDependency);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this works. If you add a test like the following:

proxy1 = use_extension(":foo.bzl", "proxy")
proxy1.tag()
proxy2 = use_extension(":foo.bzl", "proxy", dev_dependency=True)
proxy2.tag()

I believe the tag on proxy2 will be lost. (This is because the Java object backing proxy2 was never recorded anywhere; normally all proxies are recorded in extensionProxies)

What you need to do is make devDependency a parameter to the constructor of ModuleExtensionProxy, and in the if condition here, also check if devDependency matches. Then at the very end in #buildModule, you need to somehow merge two ModuleExtensionUsage objects if they only differ in devDependency. This is somewhat unwieldy but it's my first reaction.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your suggested approach is actually what I tried first, but merging the usages while preserving the orders of imports and tags proved to be rather difficult.

Instead, I am essentially creating proxy-proxies here (phew): Both proxy.withDevDependency(true) and proxy.withDevDependency(false) share the imports and tags of the original proxy and thus should make that test pass (see https://github.com/bazelbuild/bazel/pull/17909/files#diff-99af257732180398dadf7c29772bd194ca9518e59625e9ca10e3b1a31c5d9afaL553, albeit that one has a different order of dev/non-dev). Do you still see an issue here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, I see! I missed the fact that the proxy-proxies share the accumulated tags. Sorry for the noise :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

alternatively we could formulate this a bit differently. Rename ModuleExtensionProxy to ModuleExtensionUsageBuilder or something and let it have a method ModuleExtensionProxy getProxy(boolean devDependency). This way you cannot nest proxies in arbitrary depths.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that's the safer design, implemented it.

if (proxy.extensionBzlFile.equals(extensionBzlFile)
&& proxy.extensionName.equals(extensionName)) {
return proxy;
return proxy.withDevDependency(devDependency);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, I see! I missed the fact that the proxy-proxies share the accumulated tags. Sorry for the noise :)

if (proxy.extensionBzlFile.equals(extensionBzlFile)
&& proxy.extensionName.equals(extensionName)) {
return proxy;
return proxy.withDevDependency(devDependency);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

alternatively we could formulate this a bit differently. Rename ModuleExtensionProxy to ModuleExtensionUsageBuilder or something and let it have a method ModuleExtensionProxy getProxy(boolean devDependency). This way you cannot nest proxies in arbitrary depths.

@fmeum fmeum requested a review from Wyverald March 29, 2023 12:25
Copy link
Member

@Wyverald Wyverald left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks, I like this much more :)

Copy link
Member

@Wyverald Wyverald left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks!

@fmeum fmeum force-pushed the is-dev-dependency branch from 03fa693 to 11ab28c Compare March 29, 2023 14:41
@Wyverald Wyverald added awaiting-PR-merge PR has been approved by a reviewer and is ready to be merge internally and removed awaiting-review PR is awaiting review from an assigned reviewer labels Mar 29, 2023
@fmeum fmeum deleted the is-dev-dependency branch March 30, 2023 15:28
@fmeum
Copy link
Collaborator Author

fmeum commented Mar 30, 2023

@bazel-io flag

@bazel-io bazel-io added the potential release blocker Flagged by community members using "@bazel-io flag". Should be added to a release blocker milestone label Mar 30, 2023
@sgowroji sgowroji removed the awaiting-PR-merge PR has been approved by a reviewer and is ready to be merge internally label Mar 30, 2023
@Wyverald Wyverald removed the potential release blocker Flagged by community members using "@bazel-io flag". Should be added to a release blocker milestone label Mar 30, 2023
ShreeM01 pushed a commit to ShreeM01/bazel that referenced this pull request Mar 30, 2023
Allows module extensions to determine whether a given tag represents a dev dependency.

Fixes bazelbuild#17101
Work towards bazelbuild#17908

Closes bazelbuild#17909.

PiperOrigin-RevId: 520645663
Change-Id: I3e3136a09d01d25fc706bcd0dfd7e53b6e7d5285
Wyverald pushed a commit that referenced this pull request Mar 31, 2023
* Add `module_ctx.is_dev_dependency`

Allows module extensions to determine whether a given tag represents a dev dependency.

Fixes #17101
Work towards #17908

Closes #17909.

PiperOrigin-RevId: 520645663
Change-Id: I3e3136a09d01d25fc706bcd0dfd7e53b6e7d5285

* Revert section that was accidentally cherry-picked

---------

Co-authored-by: Fabian Meumertzheim <[email protected]>
Co-authored-by: keertk <[email protected]>
fweikert pushed a commit to fweikert/bazel that referenced this pull request May 25, 2023
Allows module extensions to determine whether a given tag represents a dev dependency.

Fixes bazelbuild#17101
Work towards bazelbuild#17908

Closes bazelbuild#17909.

PiperOrigin-RevId: 520645663
Change-Id: I3e3136a09d01d25fc706bcd0dfd7e53b6e7d5285
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Allow module extensions to check whether a tag is a dev dependency

4 participants