wraithan / cargo-bump Goto Github PK

First phase of getting workspace support.

https://docs.rs/cargo_metadata/0.7.0/cargo_metadata/ is the recommended way to find the manifest file and has other features like understanding workspace relationships.

This was initially reported on #9

Contenders for new TOML crate to replace tomllib.

• toml_edit - Built for cargo_edit with an very similar feature set required (may eventually see about getting bump integrated as part of cargo_edit)
  • Can preserve most formatting
    • Misses cases where the same header appears multiple times with different formats
    • Misses whitespace in headers
    • Can't find a way to preserve the whitespace around the replaced string with currently exposed data from toml_edit
    • Always adds trailing newline to file
  • Test suite includes dotted key case that causes trouble
  • Established history, maintenance within the last few months
• toml-rs - A more general purpose toml library
  • Does not preserve formatting at all
  • Extensive test suite
  • Established history, maintenance within the last few days

Lots of hacking together for the last couple steps as I trying to work out how to better interact with the toml and semver libs.

I know this is way more complicated than the fairly simple tool that you have now, but consider checking the API of the crate and determining the semver number. It's not an unheared of feature, you can find this in the package tooling of the Elm programming language.

--git-tag option will create a commit and tag with the version as the tag and message. There is no way to prefix this message. For example adding 'v' to the beginning of the commit message, tag message and tag name. This would also align with npm version and yarn version commands. The prefix might be a requirement for a version tag.

Propose a --prefix option. This option will be applied if the option --git-tag is also passed. It will prefix:

• git commit message
• tag commit message
• tag name

I will be using cargo-bump in my CI/CD setup at work to automatically update the version when a merge to development happens.

Could the functionality of cargo-bump be exposed as a library that I could use instead of having to install and compile it through cargo (the cache I am using for my github actions misses that compilation as it happens outside of the repository).

A cargo workspace with a cargo-bump-lib (lib) and cargo-bump (bin) would be a nice setup for this I believe.

I would probably be able to help with the implementation of such a lib.

The cargo-bump crate Readme file in the crates.io registry still says that it does not support git operations. Both the cargo crate and GitHub repo have the same version: 1.1.0. So please update the crate Readme file in the crates.io registry.

Cargo supports the full semver specs, which includes an optional pre-release version (eg 1.0-alpha.1) and an optional metadata (eg 0.1+2018.10.16).

Could cargo-bump support those? For example:

$ cargo bump minor --metadata $(date +%Y.%m.%d)

Part of #10 still does not include the --all case which will be worked on/committed separately

Every time I do cargo bump -g now, I get Cargo.lock as a modified file in my project root, after the commit :(

it looks like this project is abandoned. i have found: https://github.com/sunng87/cargo-release which seems like a suitable replacement. please consider archiving or adding something to the readme if you aren't going to accept pull requests or work on it anymore

I'd like to bump the package.version field without changing anything else about the user's Cargo.toml. The technique most setups use to solve this is a round trip parser. Currently there are no round trip parsers for TOML in Rust. This means I am left with either building one, working on one of the in progress efforts, attempting to solve the problem in regex, or something else silly to preserve folks style/ordering/comments

Stopgap

Until this hits 1.0 I'm not overly worried about getting this perfect. In the meantime I'm planning to just obliterate the user's Cargo.toml and generate one with [package] then [dependencies] then everything else to match common style.

There will need to be a clear warning about this in the readme and any other docs. It sucks but works well enough for my short term purposes.

Possible Solution

@joelself's https://github.com/joelself/toml_parser is top choice right now since it is being built with this purpose in mind, actively being developed, and doesn't have history to contend with. But it is greenfield, currently not published to crates.io, and doesn't support modification yet. Should I find myself squirrely enough to work on the round trip parsing problem, this is currently where I'd spend my effort.

https://github.com/alexcrichton/toml-rs is the most common parser solution for toml which I'm currently using. There is toml-rs/toml-rs#64 which looks to be adding this round trip ability, unfortunately the API ergonomics and code structure are still being debated and has been kinda dead for the last 6mo. Due to complexity and history, it is unlikely that I'd spend my time working on this.

Other stuff

There is a discourse thread about this problem. Worth monitoring for new stuff to solve it. Before trying to make progress on this ticket check that thread.

The release will likely include a new toml lib, and I'll increase the major during that. It is hard to predict if the contract will break with the new lib as formatting or other input/output characteristics could be different and easier to be conservative and bump major than be absolutely sure and only bump minor.

This was proposed as --print to print the new version number alone on a new line in #7.

Before starting to add workspace support this seemed like a good idea. Unfortunately, this very simple output doesn't allow for multiple packages to be updated, since there is no way to distinguish them.

Surveying what other cargo tools do, the biggest one folks seem to wrap is cargo_metadata which by default outputs JSON. With that in mind, perhaps we need a few output types:

• human - This output type will be default, it will likely be more verbose and include symbols to look nicer.
• simple - This output type is basically a whitespace separated vector, $crate_name $old_version $new_version. This should be easily pulled apart in bash/powershell scripts used in CI systems.
• json - This output type is to copy cargo_metadata, would be something like:

  [{"name": "cargo-bump", "old_version": "1.0.2", "new_version": "2.0.0"}]

• ndjson - This output type would basically be the above but instead of wrapping in an array, new line delimit the JSON.

This could be done as a --output $TYPE option.

We should probably try to use the same setup for JSON that cargo_metadata is using, so I don't have multiple JSON deserializers in the binary. There are already 2 TOML serializers and deserializers because we need to retain formatting, no reason to also bloat for JSON.

Removes comments, expected comments to remain

Before

[package]
name    = "ripcheck"
version = "0.0.16" # Simplified args, Threaded DNS/Rev/Arp/MACVendors/pfh/formatting/timings

After

[package]
name    = "ripcheck"
version = "0.0.17" 

Expected:

[package]
name    = "ripcheck"
version = "0.0.17"  # Simplified args, Threaded DNS/Rev/Arp/MACVendors/pfh/formatting/timings 

Work around: Place comments on previous line or following version line.

FYI: I like to keep my current commit messages (or very similar) on the version line as a comment since I use changed version numbers in those commits as well, it reminds me to keep the version numbers synchronized.

PS: Thx, I like the extension. Not a giant deal.

Note to self: Maybe keeping all of my version changing commits in my toml

When executing cargo bump minor in a workspace root, I get:

cargo bump minor
thread 'main' panicked at 'package.version missing', libcore/option.rs:989:5
note: Run with `RUST_BACKTRACE=1` for a backtrace.

I tested this with the imag source.

In atypically laid out projects, or when running outside of the project directory, or want to reference the whole workspace when in a nested project, this is how you'll let cargo-bump know what you mean.

This is postponed for now. If someone tries to add something like this, please look at what npm version does.

Something like the following:
A) Add git commit for the version bump in the Cargo.toml, optionally with a custom commit message.
B) Point a git tag named v$major.$minor.$patch at the commit made in A.

Or at least document why we don't have a --all if it doesn't make sense to add