-
Notifications
You must be signed in to change notification settings - Fork 219
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Publishing? #280
Comments
@siddontang PTAL |
We need to seriously consider this with the |
Some things we need to do/think about:
Probably more... |
@nrc Do you think extracting only the tikv related protos and making them a dependency here would be a good first step to enable this? Maybe a |
I think that is probably a good idea. I wonder whether the Raft protos should be part of that? |
These protos were too big for Raft (which is relatively small) to depend on, but the situation may change after prost |
No, raft is a standard library that should keep its own protocols. |
I don't understand either of those points, sorry.
Why is size an issue?
What do you mean by "standard" (and by implication why are TikV, etc., not standard?) |
Sorry, it should be standalone. 🤣 |
Hmm, compiling kvproto takes a long time. |
This is true of a full build (1m 16s for me), but building kvproto itself only takes 7s. Given that any deps of kvproto should be required by Raft too, it is that which matters (in practice, I think we pull in grpc-rs, which we don't really need to, I'll file an issue about that). |
That makes more sense, thanks! However, I'm still a bit unclear why Raft is a standalone library in this sense. If it is meant to be self-contained, why do we need to re-export the proto interface here? |
Because kvproto uses the struct of raft protocol directly, and due to the limited of protobuf compiler, we need to reexport raft proto interface to make the generated code compiled. |
Cool, thanks! |
Proposal:
How does that sound? @BusyJay @Hoverbear |
It sounds good to me. But I have also been thinking about removing raft dependency from kvproto, so that raft is free to change its protocols, or even no protocols at all. /cc @siddontang what do you think? |
I suppose raft and kvproto will depend on the same "raftproto" library mentioned in @nrc's comment |
@nrc I approve of this idea! |
@BusyJay @siddontang do you have any more thoughts on this? |
I just take a look into the protocols, it seems there are many places using eraft protos. It's not practical to remove the dependency now. So your proposal seems the only way to publish. |
Cool, thanks for looking at the protocols! |
We now only depend on crates.io crates, cc pingcap#280 Signed-off-by: Nick Cameron <nrc@ncameron.org>
We now only depend on crates.io crates, cc pingcap#280 Signed-off-by: Nick Cameron <nrc@ncameron.org>
We now only depend on crates.io crates, cc pingcap#280 Signed-off-by: Nick Cameron <nrc@ncameron.org>
* Use the raft-proto crate instead of raft We now only depend on crates.io crates, cc #280 Signed-off-by: Nick Cameron <nrc@ncameron.org> * Update protobuf-build Fixes a bunch of warnings Signed-off-by: Nick Cameron <nrc@ncameron.org>
Any update on publishing the crate? |
@Daniel-B-Smith We're currently not able to publish this due to some ongoing work by @nrc . We're planning to publish this crate (along with our Rust client) in Q4. Sorry for the delays. Lines 31 to 32 in 121d118
|
Thanks for the update! |
* Use the raft-proto crate instead of raft We now only depend on crates.io crates, cc pingcap#280 Signed-off-by: Nick Cameron <nrc@ncameron.org> * Update protobuf-build Fixes a bunch of warnings Signed-off-by: Nick Cameron <nrc@ncameron.org>
Any update? |
kvproto now uses forked rust-protobuf, I believe forked rust-protobuf needs to be published first. |
How can we proceed? Do we currently have any plan for the next step? |
As far as I know, no one is working on it. |
1 similar comment
This comment has been minimized.
This comment has been minimized.
Maybe related post: Move kvproto to tikv org |
I'm interested in publishing this crate so that it can be used as part of the upcoming TiKV client in Rust (which will be published on crates.io).
This already builds cleanly on nightly and has no illegal dependencies, so there should be nothing blocking publishing this.
I would recommend renaming this crate to
tikv_proto
though, so in the futuretikv_client
andtikv_server
will be consistent.The text was updated successfully, but these errors were encountered: