Closed leoluk closed 1 month ago
This does add some workarounds for e.g. https://github.com/bazelbuild/bazel/issues/19301
And to completely remove WORKSPACE we need to wait for https://github.com/rmohr/bazeldnf/issues/60
And to completely remove WORKSPACE we need to wait for rmohr/bazeldnf#60
Hmm, that's one more reason to attempt to switch to rules_nixpkgs
This does add some workarounds for e.g. bazelbuild/bazel#19301
Are we blocked on this?
This does add some workarounds for e.g. bazelbuild/bazel#19301
Are we blocked on this?
No we aren't. It's just not pretty :)
Final piece is figuring out how to replace the hardcoded external repository names (which isn't technically necessary, but Bazel doesn't consider them stable and will change them soon).
Technically not correct but we will leave it closed as we are currently only waiting for bazeldnf
Fair enough, the way we use bazeldnf isn't compatible with bzlmod anyways.
From what I understand about the design, this should allow us to depend on the monorepo from internal.git, while maintaining MVS semantics.
We should also set appropriate visibility rules to make sure we don't unintentionally expose APIs which we later regret.