Skip to content

Conversation

@grod220
Copy link
Member

@grod220 grod220 commented Sep 11, 2025

Now that spl-token-wrap is published to crates.io, the CLI helper crate will need to depend on that prior to being able to publish as well. Otherwise, it will get an error about the local dependency.

@buffalojoec
Copy link

What's the error you get? Are you sure you wouldn't rather just add the explicit version to the workspace manifest?

spl-token-wrap = { path = "program", features = ["no-entrypoint"] }

@grod220
Copy link
Member Author

grod220 commented Sep 11, 2025

What's the error you get?

error: all dependencies must have a version specified when publishing.
dependency `spl-token-wrap` does not specify a version
Note: The published dependency will use the version from crates.io,
the `path` specification will be removed from the dependency declaration.

Here's the requirement: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#local-paths-in-published-crates

Are you sure you wouldn't rather just add the explicit version to the workspace manifest?

Do you mean like this:

spl-token-wrap = { version = "1.0.0", path = "program", features = ["no-entrypoint"] }

I wonder if this is more brittle as this will work locally, but upon publish path will be removed and if the program version specified isn't published to crates.io, it will break in the action.

@buffalojoec
Copy link

Do you mean like this:

spl-token-wrap = { version = "1.0.0", path = "program", features = ["no-entrypoint"] }

I wonder if this is more brittle as this will work locally, but upon publish path will be removed and if the program version specified isn't published to crates.io, it will break in the action.

Yeah exactly. It is kinda brittle no matter how you do it, but this is the pattern we use in other places already.

https://github.com/anza-xyz/solana-sdk/blob/2cffbca31fe0ad886c340006c0e1d0136f62de02/Cargo.toml#L240

@grod220
Copy link
Member Author

grod220 commented Sep 11, 2025

Updated! @buffalojoec

@buffalojoec
Copy link

@grod220 sorry, forgot to mention you should also add version = { workspace = true } here:

version = "0.1.0"

@grod220
Copy link
Member Author

grod220 commented Sep 11, 2025

The workspace doesn't define a version that can be inherited. I'm not quite sure it should though. The two crates have to be published independently and the publish action sets the version and commits it to the repo automatically.

@buffalojoec
Copy link

The workspace doesn't define a version that can be inherited. I'm not quite sure it should though. The two crates have to be published independently and the publish action sets the version and commits it to the repo automatically.

Ah yes, you're right. Sounds good!

@grod220 grod220 merged commit 18088ac into main Sep 11, 2025
10 checks passed
@grod220 grod220 deleted the update-dep-to-remote branch September 11, 2025 14:57
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