Skip to content

Document local BCR registry for non-BCR dependencies #62

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.

Sign up for GitHub

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

Open
manuelnaranjo wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Document local BCR registry for non-BCR dependencies #62

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 13 additions & 0 deletions SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -237,6 +237,19 @@ rather than recalled). Put `common --check_direct_dependencies=error` in the
generated `.bazelrc` so a declared version that MVS overrides fails the build
instead of being a warning nobody reads.

Third-party dependencies that are not in the Bazel Central Registry (BCR) must
be added to a **local BCR registry** inside the repository (e.g. `registry/`

@armandomontanez armandomontanez Oct 28, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

IMO this depends on whether or not the resulting project will be in the BCR. If it's for an internal migration, this is totally fine. If the migrated project will live in the BCR, referencing nonexistent modules makes it a broken dependency.

Typically to be safe, I use http_archive or new_local_repository until the dependency is migrated to also be a Bazel module.

@manuelnaranjo manuelnaranjo Oct 28, 2026

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

I agree that if you plan to publish into BCR using a local index is a problem, on the other hand my approach has 2 advantages IMO:

  • Easier to contribute back to BCR as the dependency is already in a state that's contributable.
  • Cleaner MODULE.bazel specially if you have 10s of missing dependencies like I'm getting

Maybe the skill should ask the user for which style to adopt? Not sure if that's possible

@armandomontanez armandomontanez Oct 28, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Stop-and-ask does tend to work (key word being "tend"), but generally we're moving to more automation in favor of stop-and-ask. Also, external dependency handling is a bit of an open question so this may churn a bit as we explore what's best.

This guidance is reasonable if we also direct agents to clarify that using a local registry is considered an intermediate step until external dependencies are added to the BCR. i.e. let's add a snippet that directs agents to flag the external dependencies that are missing from the BCR that should be added before this project works as a BCR dependency.

containing `bazel_registry.json` and `modules/<name>/<version>/...`) and
depended on via `bazel_dep` in `MODULE.bazel`. Make the local registry available
to Bazel with `--registry` by adding **two** entries to `.bazelrc` — one for the
local registry first, and one for the public BCR second (passing `--registry`
replaces Bazel's default registry list):

```text
common --registry=file://%workspace%/registry
common --registry=https://bcr.bazel.build
```

### Main migration loop {#main-migration-loop}

#### Extract the Bazel action graph {#extract-bazel-graph}
Expand Down