Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: single source of truth for crate versions #2075

Closed
Diggsey opened this issue Oct 22, 2015 · 5 comments
Closed

Feature request: single source of truth for crate versions #2075

Diggsey opened this issue Oct 22, 2015 · 5 comments
Labels
A-configuration Area: cargo config files and env vars C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`

Comments

@Diggsey
Copy link
Contributor

Diggsey commented Oct 22, 2015

Often you need to specify the crate version in several places:

  • Cargo.toml
  • CLI config file (to support --version)
  • Within the code itself

Additionally, you sometimes have several crates within the same repository, whose versions you want to keep in lock-step. The crate version must then additionally be specified:

  • In the sub-crate's Cargo.toml
  • Within the [dependencies] section of the parent Cargo.toml

For more complex projects, it's easy to imagine that there's other information which may be desirable, eg. git commit hash, build date, and additional configuration options (think rust's channel system).

All in all, this can make publishing a new version somewhat tedious and error-prone. Honestly I don't know what a good and general solution is that covers all of these cases.

Currently the only way I can see of doing it would be to turn most of the project into template files which are passed through a pre-processor by the build script, but this is extremely intrusive, and wouldn't work for redundancy within Cargo.toml itself.

@alexcrichton
Copy link
Member

For code at least cargo will pass the version as an environment variable (accessible via env!), but between Cargo.toml instances this can definitely be a problem.

@rtaycher
Copy link

For simple one crate binaries clap-rs reads the aforementioned env variable w/ crate_version! macro, and could be added to docopt and getopts.

@carols10cents carols10cents added A-configuration Area: cargo config files and env vars C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted` labels Sep 10, 2017
@mitsuhiko
Copy link
Contributor

With the new workspaces feature this is becoming a bit more relevant now I think. We just set up a larger Rust project into many independent sub crates which we want to release together. Right now I'm planning on making a script that bumps all versions in one go but not having to do that would be great.

@epage
Copy link
Contributor

epage commented Apr 21, 2022

In the sub-crate's Cargo.toml

With rust-lang/rfcs#2906

Workspace

[workspace]
version = "1.2.3"

Crate

[package]
name = "foo"
version.workspace = true

Within the [dependencies] section of the parent Cargo.toml

rust-lang/rfcs#2906 provides a solution for this but it is a breaking change so in #8415 we are proposing to drop it.

Using something like cargo-release helps. When you bump the version of one crate it automatically updates all dependency specifications pointing to that crate. It also supports replacements so you can update versions in install instructions, etc.

For more complex projects, it's easy to imagine that there's other information which may be desirable, eg. git commit hash, build date, and additional configuration options (think rust's channel system).

I'd recommend checking out https://github.com/baoyachi/shadow-rs or https://github.com/rustyhorde/vergen

@weihanglo
Copy link
Member

Since this is a quite old issue, I am going to close it. Cargo's workspace inheritance should help with that in most use cases.

For other feature requests and alternatives, read Ed's comment #2075 (comment). If you want to integrate cargo-release or other build time information into Cargo, please file an issue with a clear scope. That would be easier to reason and get done. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-configuration Area: cargo config files and env vars C-feature-request Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`
Projects
None yet
Development

No branches or pull requests

7 participants