Skip to content

Conversation

@mfahampshire
Copy link
Contributor

@mfahampshire mfahampshire commented Dec 4, 2025

This PR is prep work for publishing the Rust SDK + its workspace dependencies to crates.io.

Overall, this PR:

  • defines a workspace version for all the sdk workspace dependencies + the nym-sdk crate; we want to keep them all in line with each other

  • adds a script to use cargo release to publish the SDK + its dependencies - cargo release deals with creating them in the correct order

  • when happy, remove --no-publish from the script

  • rename wasm-utils to nym-wasm-utils

  • test with nym-sphinx crate + deps

  • look into more automated tool (create or find) for sdk - nym-sphinx crate feels laborious and the current setup a bit fragile. Do some 🦆 -ing.

  • bump ALL VERSIONS to 1.20.1 and republish when deploying SDK

  • make PR to vpn repo to update sqlx-guard to nym-sqlx-guard


This change is Reviewable

@vercel
Copy link

vercel bot commented Dec 4, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Preview Comments Updated (UTC)
nym-explorer-v2 Ready Ready Preview Comment Dec 5, 2025 8:59pm
2 Skipped Deployments
Project Deployment Preview Comments Updated (UTC)
docs-nextra Ignored Ignored Preview Dec 5, 2025 8:59pm
nym-node-status Ignored Ignored Preview Dec 5, 2025 8:59pm

Cargo.toml Outdated
license = "Apache-2.0"
rust-version = "1.85"
readme = "README.md"
version = "1.20.0" # this version is used for the Rust SDK and its workspace dependencies, it is not applied globally
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

by "its workspace dependencies", do you been exlusively things that are used by rust SDK or all common crates (I think it'd be good to keep it consistent for everything, especially if we were to add an extra dep to rust sdk)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its the crates that are used by the SDK only currently - I've added a note in the publishing.md file in the SDK re: adding workspace deps to the SDK

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my previous comment has become moot with my previous commits making basically everything aside from the binaries/contracts/tools follow the versioning structure, sidesteps this potential issue.

Cargo.toml Outdated

# sdk related deps so we can pull in workspace versions of these in other crates' cargo files, and not have to define the version everywhere
# nym-api = { version = "1.2.0", path = "nym-api" }
nym-bandwidth-controller = { version = "1.2.0", path = "common/bandwidth-controller" }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure you have to specify the version on top here (plz double check), but if not, i'd remove it so we wouldn't cause some inconsistencies if we forget to update those

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was the hacky way I found which allows us to define the workspace.version for the constituent crates. Maybe I can get rid of those.. Will experiment.

[package]
name = "sqlx-pool-guard"
version = "0.1.0"
name = "nym-sqlx-pool-guard"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since you've renamed this, after the PR gets merged, create a draft on the vpn repo to update their dependencies (as they were importing it too)

publish-sdk.sh Outdated
--prev-tag-name "" \
--no-push \
--no-tag \
--no-publish \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, if we actually want to publish it, we probably want to remove this flag : )

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah will remove once we're happy with the dryrun and setup - was being doubly cautious so I didn't accidentally publish them when testing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants