So, I think I understand where the original work is coming from, but
fundamentally disagree with its implementation.
The idea was to create "drop in" macros that you can use to easily
create rust pb bindings, abstracting over the varied and complex tooling
that the rust ecosystem requires.
I believe this to be a mistake:
1. Potential for version mismatch for rlib symbols
Anyone who remembers the "bad old days" of tokio 0.x (and futures
0.1, for that matter) knows the pain of attempting to link against
two different versions of the same symbol, because some dep you have
is using an older version of the exported symbol.
The use of "bundled" fallbacks in the varied xxx_dep(s) macro args
invite this same issue.
Instead, callers should made aware of the needed deps and be
required to provide their own, ensuring their projects remain
coherent.
The bundled should *only* be used for creating the needed binaries
for protoc codegen
2. Focus on UX over documentation
The entire //rust:... subsystem of this project is misleadingly
documented, to the point that it is easier to simply read the
entire code base, rather than the docs.
There was an attempt to compensate for this via the examples/ and
ease-of-use in the public macros and rules, however the lack of
documentation leaves users that need to integrate with more complex
monorepos completely confused about how to correctly satisfy the
mandatory args, what expected values for these args are, etc
Therefore, this refactor of the top level *_library macros adds proper
documentation each, and simplifies the args and notifies the caller of
the requirements to call each macro.
Paul Stemmet
87aee8e13b
