tikv/client-rust

Resolving blockers for publishing

Hoverbear opened this issue · 8 comments

Hoverbear commented

This crate is intended to be published to the Crates.io registry to support our users easily (and correctly) depending on this client.

It will also enable future cargo install tikv-client uses for our command line tool (#17).

The current blockers:

  • CI is red (fixed by #22 and #30)
  • No README (fixed by #31)
  • KVproto is a git based dependency (this is a hard blocker for publishing. pingcap/kvproto#280)

These issues prevent us from reaching a published 0.0.1 release.

florianeichin commented

Is there a plan on when version 0.0.1 is released to crates, as the module is not usable as described in the readme

Hoverbear commented

@florianeichin When the blockers listed above are resolve! :)

thinktainer commented

What approaches have been considered on how to address the KVproto dependency blocker? just saw the open pr for this.

nrc commented

To summarise the problem:

  • All our deps must be published
  • kvproto (unpublished) depends on protobuf-build (unpublished)
    • publishing kvproto also opens questions about what to do with the Go code, etc.
  • protobuf-build depends on PingCAP's fork of rust-protobuf
    • it would be a relatively large amount of work, and uncertain, to try and upstream our changes
    • rust-client only uses Prost, so this is kind of a limitation of Cargo

So, possible solutions:

  • publish kvproto, requires
    • upstreaming changes to rust-protobuf
    • or publishing our fork of rust-protobuf (easiest, but not popular on tikv/protobuf-build#31)
    • removing the rust-protobuf dependency from protobuf build, either by removing rust-protobuf support from TiKV (hard) or by implementing some kind of pre-build step.
    • implement a separate version of protobuf-build which only supports Prost as a new project
  • Copy the protos we require to the client repo. However, we'd still need to fix the dependency of protobuf-build, as above. We could do our own protobuf codegen.

The easiest solution seems to me to be to copy protos to the client repo and to do our own codegen rather than rely on protobuf-build.

nrc commented

Actually it seems that protobuf-build does not depend on our fork of protobuf, it depends on upstream. So maybe we can just copy the protos we need and we're done :-)

jerrygreen commented

Blockers resolved, but still no crate?

nrc commented

Blockers resolved, but still no crate?

Indeed, we're working on getting the quality to a point where we're satisfied enough for a 0.1 release. Hopefully we should have a release in the next month or so.

  • 👍2