Resolving blockers for publishing

[Hoverbear]

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 Refine CI #22 and Bump Kvproto #30)
• No README (fixed by Add README and some lib.rs docs #31)
• KVproto is a git based dependency (this is a hard blocker for publishing. Publishing? pingcap/kvproto#280)

These issues prevent us from reaching a published 0.0.1 release.

[florianeichin]

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]

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

[thinktainer]

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

[nrc]

See also tikv/protobuf-build#31

[nrc]

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 Use a published version of the rust-proto branch 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]

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]

Blockers resolved, but still no crate?

[nrc]

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.