Yank and reserve rules_objc

[meteorcloudy]

In the last rules authors meeting, we have decided to enforce a higher standard for rules_* modules and will require approval from the rules authors meeting.

The current rules_objc checked in #7894 won't meet those requirements, therefore we have decided to yank the current version.

[bazel-io]

Hello BCR maintainers, modules with only metadata.json changes (rules_objc) have been updated in this PR.
Please review the changes.

[meteorcloudy]

@kekxv Do you mind submitting your module under a new name like kekxv_rules_objc? Sorry for the inconvenience, but we want to make sure all rules_* modules are mature and well-maintained to avoid causing too much confusing for users.

Require module maintainers' approval for newly pushed changes.

[kekxv]

@meteorcloudy
Got it, but I still think it essentially boils down to this: https://github.com/bazelbuild/bazel-central-registry/discussions/6708

[meteorcloudy]

Yeah, that's why we need a clear guideline for rules_* modules, I will try to publish one soon.

[kekxv]

@meteorcloudy

Is it possible to support a 'user-space' mode? For example, by using @github.com/kekxv/rules_objc and having the Bazel client handle it directly without going through the server. Could this be implemented via Bazel itself or a special module?

Although Bazel supports custom central registries, it's not very convenient for people outside of specific teams.

[meteorcloudy]

What do you mean specifically? My feeling is probably no and we won't have capacity to implement that.

[kekxv]

Is there a way to enable both custom third-party repos and the official registry solely through .bazelrc or MODULE.bazel?

I'd like to try the following approach to see if it works:

common --registry=https://bcr.bazel.build
common --registry=https://my-private-registry.com

[meteorcloudy]

common --registry=https://bcr.bazel.build
common --registry=https://my-private-registry.com

This should work, but maybe you want to put your private one in front of BCR