Adding a top-level build-file argument to git_override

[nicholasjng]

I was wondering if it would make sense to include a build file slot in the git_override method (and possibly the others too) in MODULE.bazel.

My angle is trying to pull in a git dependency that does not have a Bazel integration, and thus needs a proper build file marking it as a package. This used to work by checking in a build file and giving it to the git_repository function, but bzlmod's overrides do not have such a slot.

I know that I can probably keep my build file from the workspace era in my main repo and make a patch out of it (does anyone have a nice shell snippet for that by the way, generating a whole-file patch of a checked-in file?), but I think this would be so much of a UX improvement that I'd like to see it. How do others feel about this?

[fmeum]

You can still use the git_repository repository rule from your module file via use_repo_rule. git_override is less convenient anyway as you will also have to specify a MODULE.bazel file for your dependency. With use_repo_rule, it just inherits the dependencies of your root module.

[nicholasjng]

No, that's not what I'm looking for - nanobind is not a great fit for package managers and registries because it is so configurable and has lots of platform-, Python version-, and feature-dependent optimizations and build flags.

For that reason, nanobind itself recommends building it inplace for your specific application, and I agree with this reasoning, which is why I wanted to find a way to bootstrap it from a git repo using bzlmod. But it seems the git_repository rule is the best fit for this need as it stands.

[meteorcloudy]

Just to be clear, the current nanobind module is built from source (like most modules in BCR), but I understand it might not be flexible enough to be configured by the end user. However, it's definitely feasible to have better integration with Bzlmod to make it possible.
https://github.com/bazelbuild/bazel-central-registry/blob/main/modules/nanobind/1.2.0/patches/add_build_file.patch#L4

[nicholasjng]

Yeah, that's my gripe with that workflow - that tag was pushed for Google benchmark, and I changed some of the build and linker options afterwards.

Also, if you decide to change the options, do you just clobber the tag and change options for everyone in the BCR? I don't think that's good.

[meteorcloudy]

No, I meant something like https://docs.google.com/document/d/132vEDnQZY0PtF9ko6HoLQ2dqk6meZnSrUfc1gsKuBkk/edit for #16552

The end user should have the control. But if having multiple copies for nanobind is generally fine and won't cause any conflict, then yes, probably it's better for everyone to have their own version.

[nicholasjng]

Fair, then I still need to pull in the C headers of the target Python version (which is hardcoded to 3.8 in BCR nanobind, oof), but @rules_python//python/cc:current_py_cc_headers might let me.

If you provide these symbols for the users, you're giving a lot of value already. But even then, you might still want to give the option of rolling your own module/build file entirely, since the customization level is already considerably high.

By the way, thanks for the comments! It's very valuable to me to have this kind of exchange with actual experts, because (IMO) the docs are not exhaustive in many places for the casual user.