Skip to content

Conversation

fmeum
Copy link

@fmeum fmeum commented Aug 1, 2024

Bazel 6 introduced a new system for managing external dependencies centered around the concept of Bazel modules, which are hosted in a registry. The default registry is the Bazel Central Registry. This system will become the default this year and its predecessor will be turned off next year.

As discussed in bazelbuild/bazel#23166, we would thus like to register the bazel purl type for Bazel modules, as specified in this PR.

(Approved by the Rules Authors SIG: https://docs.google.com/document/d/1YGCYAGLzTfqSOgRFVsB8hDz-kEoTgTEKKp9Jd07TJ5c/edit#heading=h.9h67icc19g8f)

@fmeum
Copy link
Author

fmeum commented Aug 6, 2024

CC @mzeren-vmw

@oej
Copy link

oej commented Aug 7, 2024

Any status on the feedback you waited for?

@fmeum
Copy link
Author

fmeum commented Aug 7, 2024

@oej Yes, this has been approved and is ready for review!

@fmeum fmeum marked this pull request as ready for review August 7, 2024 09:05
@fmeum
Copy link
Author

fmeum commented Aug 21, 2024

@stevespringett Could you review this?

@fmeum
Copy link
Author

fmeum commented Oct 9, 2024

@pombredanne Not sure who to ask for a review, could you take a look?

@johnmhoran johnmhoran added the type: bazel Proposed new type label Oct 19, 2024
@jkowalleck jkowalleck changed the title Add bazel type for Bazel modules propose bazel type for Bazel modules Oct 19, 2024
fviernau added a commit to oss-review-toolkit/ort that referenced this pull request Nov 21, 2024
fviernau added a commit to oss-review-toolkit/ort that referenced this pull request Nov 22, 2024
@sschuberth
Copy link
Member

@fmeum please rebase to resolve conflicts.

@fmeum
Copy link
Author

fmeum commented Nov 22, 2024

@sschuberth Done

fviernau added a commit to oss-review-toolkit/ort that referenced this pull request Nov 22, 2024
@fmeum fmeum requested a review from sschuberth November 22, 2024 10:04
sschuberth pushed a commit to oss-review-toolkit/ort that referenced this pull request Nov 22, 2024
PURL-TYPES.rst Outdated
- The ``version`` is the module version in `Bazel's relaxed semver format
<https://bazel.build/external/module#version_format>`_.
- The optional ``repository_url`` can be used to specify the URL of an
alternative registry, with any trailing forward slashes removed.
Copy link
Member

Choose a reason for hiding this comment

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

with any trailing forward slashes removed.

I'm not sure about that bit. This is not one of the "type-specific normalizations" that are allowed for the namespace segments and name. And semantically, having a trailing slash or not does not make a difference for the URL.

Copy link
Author

Choose a reason for hiding this comment

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

I just dropped this in a new commit.

@fmeum fmeum requested a review from sschuberth November 22, 2024 12:10
sschuberth added a commit to oss-review-toolkit/ort that referenced this pull request Nov 22, 2024
sschuberth added a commit to oss-review-toolkit/ort that referenced this pull request Nov 22, 2024
The algorithm description at [1] demands to "apply type-specific
normalization" to namespace segments and the name before applying
percent-encoding. In general, type-specific requirements are documented
at [2]. For Bazel the PR still pending, but in the current state
lowercasing of the name should be performed [3].

[1]: https://github.com/package-url/purl-spec/blob/master/PURL-SPECIFICATION.rst#how-to-build-purl-string-from-its-components
[2]: https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst
[3]: package-url/purl-spec#317

Signed-off-by: Sebastian Schuberth <[email protected]>
sschuberth added a commit to oss-review-toolkit/ort that referenced this pull request Nov 22, 2024
The algorithm description at [1] demands to "apply type-specific
normalization" to namespace segments and the name before applying
percent-encoding. In general, type-specific requirements are documented
at [2]. For Bazel the PR still pending, but in the current state
lowercasing of the name should be performed [3].

[1]: https://github.com/package-url/purl-spec/blob/master/PURL-SPECIFICATION.rst#how-to-build-purl-string-from-its-components
[2]: https://github.com/package-url/purl-spec/blob/master/PURL-TYPES.rst
[3]: package-url/purl-spec#317

Signed-off-by: Sebastian Schuberth <[email protected]>
@fmeum fmeum requested review from jkowalleck and Yannic March 4, 2025 12:00
jkowalleck
jkowalleck previously approved these changes Mar 4, 2025
PURL-TYPES.rst Outdated
``bazel`` for Bazel modules as specified at ``https://bazel.build/external/module``:

- The default repository is the Bazel Central Registry (BCR) ``https://bcr.bazel.build``.
- The ``name`` is case sensitive and must not be modified.
Copy link
Member

Choose a reason for hiding this comment

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

I am not sure where case sensitivity is defined this way?
The definition https://bazel.build/rules/lib/globals/module#parameters_6 seems quite explicit to me wrt. the name case in the module method (emphasis added):

name string; default is ''
The name of the module. Can be omitted only if this module is the root module (as in, if it's not going to be depended on by another module). A valid module name must: 1) only contain lowercase letters (a-z), digits (0-9), dots (.), hyphens (-), and underscores (_); 2) begin with a lowercase letter; 3) end with a lowercase letter or digit.

Copy link
Author

Choose a reason for hiding this comment

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

Let me start by saying that I don't particularly mind how this is formulated. I'm just interested in getting the purl type registered.

The name isn't case sensitive in the sense that for each string, there is only ever at most one Bazel module name that is equal to it ignoring case.
The name is case sensitive in the sense that specifying a module name with any casing other than lower case will result in an error shown by Bazel.

Copy link
Contributor

Choose a reason for hiding this comment

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

I agree that it is case sensitive in that case.

If you can use Bazel to install SHOUTING_MODULE and it installs shouting_module, then it is case insensitive. However, if installing SHOUTING_MODULE is an error, it's possible that in the behavior will change or has changed, at which point PURL implementations will be automatically converting one package name into another package name like what happens with pkg:npm/jQuery which gets replaced by pkg:npm/jquery because the current rules forbid uppercase and past rules did not.

Besides the possibility that rule changes cause aliasing problems, it just doesn't seem like a good or useful idea to specify that if the user provides an invalid module name the PURL implementation must automatically convert it into a valid module name.

Copy link
Member

Choose a reason for hiding this comment

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

exactly.

and in addition: #317 (comment)

Note that different casings can also happen if private registries are involved [...]

jkowalleck
jkowalleck previously approved these changes Apr 4, 2025
@johnmhoran johnmhoran added this to the 1.0-draft milestone Apr 4, 2025
@mjherzog mjherzog modified the milestones: PURL-Spec v1.0, PURL-TBD May 27, 2025
Copy link

@Yannic Yannic left a comment

Choose a reason for hiding this comment

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

Having worked on https://github.com/bazel-contrib/supply-chain for the last few month, I'd really like to see this land sooner than later.

@pombredanne
Copy link
Member

After the merge of PR #514, PURL tests and defs are now defined in new JSON schemas 👼 😇 😁 :

... therefore with the new approach... this PR would need to be updated.

Do you think you can update this PR to the new format?

Sorry for the churn. ❤️

@fmeum fmeum requested a review from jkowalleck July 29, 2025 19:41
@fmeum
Copy link
Author

fmeum commented Jul 29, 2025

@pombredanne PTAL

@jkowalleck jkowalleck requested review from a team and removed request for matt-phylum August 6, 2025 09:26
@fmeum
Copy link
Author

fmeum commented Aug 27, 2025

@jkowalleck Friendly ping, what is needed to get this merged?

@jkowalleck jkowalleck requested a review from a team September 3, 2025 08:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants