-
Notifications
You must be signed in to change notification settings - Fork 197
propose bazel
type for Bazel modules
#317
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
base: main
Are you sure you want to change the base?
Conversation
CC @mzeren-vmw |
Any status on the feedback you waited for? |
@oej Yes, this has been approved and is ready for review! |
@stevespringett Could you review this? |
@pombredanne Not sure who to ask for a review, could you take a look? |
bazel
type for Bazel modulesbazel
type for Bazel modules
See also [1]. [1]: package-url/purl-spec#317 Signed-off-by: Frank Viernau <[email protected]>
See also [1]. [1]: package-url/purl-spec#317 Signed-off-by: Frank Viernau <[email protected]>
@fmeum please rebase to resolve conflicts. |
@sschuberth Done |
See also [1]. [1]: package-url/purl-spec#317 Signed-off-by: Frank Viernau <[email protected]>
See also [1]. [1]: package-url/purl-spec#317 Signed-off-by: Frank Viernau <[email protected]>
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. |
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.
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.
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 just dropped this in a new commit.
See [1]. [1]: package-url/purl-spec#317 Signed-off-by: Sebastian Schuberth <[email protected]>
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]>
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]>
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. |
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 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.
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.
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.
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 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.
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.
exactly.
and in addition: #317 (comment)
Note that different casings can also happen if private registries are involved [...]
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.
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.
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. ❤️ |
@pombredanne PTAL |
@jkowalleck Friendly ping, what is needed to get this merged? |
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)