propose bazel type for Bazel modules
#317
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? |
jkowalleck
changed the title
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.
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.
I just dropped this in a new commit.
PURL-TYPES.rst
Outdated
| - The optional ``subpath`` can name a particular Bazel target in the module via | ||
| a label with the leading double slash (``//``) removed and canonicalized by | ||
| omitting the target name if it is equal to the name of the containing package. |
There was a problem hiding this comment.
Hmm. The spec describes the subpath as
extra subpath within a package, relative to the package root.
How is what you describe "relative to the package root"? Would a custom qualifier maybe make more sense to store the Bazel target?
There was a problem hiding this comment.
I simplified this part of the spec in a new commit so that it's always a regular file path, corresponding to a package (not target or file) in the Bazel module. This is analogous to the usage of subpath for golang.
There was a problem hiding this comment.
Looks good to me now, but I'd like others to share their opinion as well.
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]>
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]>
Two approvals are needed since recently. Maybe @pombredanne can also review? |
|
@sschuberth I think this now has the second approval? |
|
Unfortunately, @Yannic you have read-only permissions, so the approval does not count towards mergability:
|
|
@sschuberth Do you happen to have write permission and could add the second approval yourself? |
@fmeum As mentioned over here I'm currently pausing reviews to this project until some process question are clarified with @pombredanne. |
Oh! Sorry, I was under the impression that you already approved. I'm aware that my LGTM doesn't count towards the two required approvals. @sschuberth do you have a rough estimate on when you expect the process questions to be resolved? A few days? A few weeks? I'm asking mostly to understand when Fabian or me should follow-up here so we don't unnecessarily ping :) |
I simply have no idea. I've already reached out the respective people, but I'm not getting any answer. But I'll keep on pushing 😉 |
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
bazelpurl 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)