Mikhail Mazurskiy

> Do you have an example of how you expect to use the rules? [Here](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/build/proto.bzl) is what I currently do using [my own plugin definition](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/build/validate.bzl). I pretty much [swapped](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/merge_requests/520) my...

I've just ran into this issue. But I think everything is working as intended - `native.bazel_version` is only available to repository rules i.e. it cannot be used from a `BUILD`...

If you want a more up to date version you are welcome to send a PR :)

> that it's possible you'd want to adjust the read limit depending on the user and whether they're verified/logged in That sounds like a very specific requirement that can be...

> The reason read limit is in the library at all is so that a proper error message is written to the peer. Using io.LimitReader for example will return an...

Another idea: make `HTTPClient` field in `DialOptions` an interface to allow to inject custom client implementation/wrapper/mock.

Well, I don't remember what the problem was.

This is causing some grief again...

Workaround is to define custom rules like so: ```starlark load( "@rules_proto_grpc//:defs.bzl", "ProtoPluginInfo", "proto_compile_attrs", "proto_compile_impl", ) go_grpc_compile = rule( implementation = proto_compile_impl, attrs = dict( proto_compile_attrs, _plugins = attr.label_list( providers =...

Yes, moving the helpers out e.g. into an example that can be copied or into a separate module would be good to avoid transitive dependencies.