fmeum
commented
2 weeks ago I think that if we want to add support for this, we should also consider the "single-module registry" idea that has been floated around before. Assuming that a Git repo contains a version of a Bazel module with other versions available in the BCR, we could conceivably allow deps such as:
bazel_dep(name = "github.com/org/repo", version = "v1.2.3-20191109021931-daa7c04131f5") (inspired by Go's pseudo-version).
Such a dep would not need to count as an override as its version is amenable to relaxed semver comparison (the format needs to be slightly more complex if the base tag itself uses relaxed semver or -).
The advantage is that projects could choose to depend on deps that aren't in the BCR yet at all. Hopefully the more cumbersome dep statement would still encourage users to add released versions to the BCR.
meteorcloudy
Description of the feature request:
The FR is for the BCR to allow uploading release candidate versions to the registry, which might be git repositories (rather than HTTP archives).
So really there are two related items:
2.0.0-alphais a higher version than1.0.0but a lower version than2.0.0), though the documentation implies this is already the case.It's possible that we might want special handling of release candidate versions (e.g., warn the user if version resolution bumps them from a stable version of a transitive dependency to a release candidate; skip release candidates when incrementing versions if the corresponding released version is also in the BCR, i.e. prefer going from
1.0.0straight to2.0.0if it's available, rather than2.0.0-alpha). To support this, release candidate versions might need special metadata.@Wyverald
Which category does this issue belong to?
External Dependency
What underlying problem are you trying to solve with this feature?
Pigweed (a Bazel module) depends on the pico-sdk (another Bazel module), but has a higher release cadence. We effectively release Pigweed continuously, while the pico-sdk has historically been released only once every few months.
This leads to issues when a bug affecting Pigweed is discovered in the pico-sdk. Even once the fix is merged into the upstream pico-sdk, we can't rely on the fix in Pigweed until a release is cut. For local development, we can use a
git_override, but there's no way for downstream users of Pigweed to inherit this when they specify a version of Pigweed that needs the fix as abazel_dep. This means we need to go beyond the BCR for managing dependencies (e.g. through maintaining our own registry).To continue expressing our dependencies exclusively via the BCR, we'd like to be able to say that we depend on the release candidate (even though the release has not been cut yet, and there's no HTTP archive). Note that this is different from patching the pico-sdk in the BCR. We don't want to patch it. We just want to make the BCR versions more granular than the GitHub releases.
Another dependency for which we'd like to do something similar is
rules_cc. There's a release candidate forrules_cc(actually a HTTP archive!) that introduces a new API. But it's not officially released yet, and so not in the BCR.The reality of software development is that different projects have wildly different release cadences, and so sometimes modules need to depend on yet-unreleased versions of other modules. It should be possible to express this through the BCR.
As Bazel is adopted by large, multi-build system projects, being able to decouple BCR versions from official releases in this way will become increasingly important. These projects will not always be releasing frequently enough for the ecosystem to rely exclusively on released versions, and their maintainers may be unwilling to cut releases just to make their (relatively few) Bazel users' dependency management tidier.
Which operating system are you running Bazel on?
Any
What is the output of
bazel info release?No response
If
bazel info releasereturnsdevelopment versionor(@non-git), tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse HEAD?No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
See https://issues.pigweed.dev/issues/360950550#comment3 and following for further context. Basically, this FR attempts to propose a long-term solution for managing unreleased dependencies that falls short of setting up separate registries.