Publishing the parser to crates.io

[charliermarsh]

👋 I know there's a line in the README about publishing to crates.io, but I just wanted to upvote it and couldn't find a better avenue to do so. We use the LibCST parser to support some autofixes in Ruff, and we currently package LibCST as a Git dependency. It'd be more convenient and reliable to pull it in from crates.io (we occasionally see spurious network failures with Git dependencies), and would also enable us to publish Ruff itself to crates.io in the future.

Alternatively, if there isn't interest from the maintainers in publishing this to crates.io, is there any way you'd be open to having me publish (e.g.) an undocumented ruff_libcst package of a fork?

Thanks!

[zsol]

hey @charliermarsh i'd be happy to publish to crates.io if someone could contribute automation similar to the existing publishing pipeline for pypi.

[manmartgarc]

Just to confirm, would making a GitHub workflow similar to this be sufficient?

[zsol]

Yes.

[jelmer]

FWIW it'd be great to see this from a Debian perspective, working on packaging ruff.

[manmartgarc]

Wondering how to handle the cargo registry token. This is about ownership of the package on the registry. After looking here it seems that it can be set as a repository secret on the GitHub repository.

I am guessing @zsol or some maintainer of LibCST would like to keep ownership of the create on the registry. Happy to hear any feedback. Apologies in advance if there is already a defined approach in the community, but this is the first time I am handling the cargo ecosystem.

[zsol]

Yes, Meta wants to retain ownership of the crate. I'm happy to do whatever's necessary to obtain the tokens

[zsol]

I've got https://crates.io/crates/libcst and https://crates.io/crates/libcst_derive published manually to make sure the names are ours, but they're both at version 0.1.0 for now.

[manmartgarc]

Amazing, thanks. I will probably submit the PR on dry build mode, and the exact environment variable name can be set from the repo secrets then. Edit: referring to the repo secret variable name in the PR.

[manmartgarc]

Bumping this. A PR is open for fixing this: #1012