[Feature Request] Publish client crate to crates.io

[Sushisource]

Regardless of the whether or not we're moving forward with a full Rust SDK, we should publish the client crate at some point so that's more easily consumable.

[cretz]

I don't think it should be published from this repo. Properly publishing IMO requires proper tagging which IMO we shouldn't make sdk-core have to do. It will be confusing to have to concern ourselves with SDK core tagged versions for directly-using users while SDK users are based on commits.

I would totally support a sdk-rust repo with a (alpha versioned) client crate that may mostly pub use stuff from this repo. Maybe it's not even a client create, but just a temporalio crate and we can feature gate things later if we have dependency concerns between workers and clients. The sdk-core repo can be a submodule from that sdk-rust repo too since I think relative project reference is safer than git reference from Cargo (having submodules stuck on a specific commit for other SDKs has been a great help of allowing core to move forward independently from SDKs).

[9999years]

It will be confusing to have to concern ourselves with SDK core tagged versions for directly-using users while SDK users are based on commits

This also means that no crates which use these SDKs can be published to crates.io, because crates.io forbids publishing crates which have Git dependencies. This makes it very difficult to share work which builds on these APIs.

[cretz]

This is an intentional side effect because the APIs in this crate have no stability guarantees and therefore should not be depended upon by published crates to be downloaded transitively. The code in this repo is meant to be "vendored"/embedded in other Rust crates not depended upon in Cargo.toml by version. We do hope to have a Rust SDK in the future that will be stable and versioned.

[lf-]

This is an intentional side effect because the APIs in this crate have no stability guarantees and therefore should not be depended upon by published crates to be downloaded transitively

There is a viable solution to this, you set the version to 0.20250207.0 or even just 0.0.1 or similar. You don't have to have a stability guarantee to release stuff, just automate the release process and just release it.

[lf-]

If you want an example of how to do release automation for Rust, my colleague has written one here and it could be adapted: https://github.com/MercuryTechnologies/ghciwatch/blob/main/.github/workflows/release.yaml

It automates the process of making a release when a PR is submitted such that you just have to label the PR and it will bump the version as appropriate.

[cretz]

The concern is not whether we can publish the crate (we definitely can), it's the implication of having a published crate for this repo which tacitly encourages people to depend on it in their Cargo.toml for their published library which we are discouraging.

I would encourage https://github.com/MercuryTechnologies/hs-temporal-sdk and similar repos to use this repo as a git submodule or similar (this is what we do in other SDKs using this repo).

[jayy-lmao]

It would be good to have option of installing a 0.0.1 version crate or something though. Requiring it to be a git submodule (or even a cargo git dependency) can be very limiting to the architecture decisions of its consumers. Also if standardising across several services or against examples it can be less simple to make sure you are ultimately running the same version.

Vendoring/Embeddings very non-standard for Rust as far as I've seen, and pre-v1 crates are more commonly the norm.