killercup
cargo-upgrade feedback
When running in a workspace with parse-display 0.7.0 and parse-display 0.8.0 available
Running this
cargo upgrade -p parse-display
outputs this:
Excluded list contains a bit more info than is useful - a list of all the crates it didn't updated, including workspace members which it can't possibly update.
This also does nothing to parse-display. Incompatible version is mentioned several times but unless you scroll up through several pages of output - it's impossible to see.
When I ask to upgrade a specific crate - I would expect more info about what happened to it. Upgraded, not upgraded, etc.
Running this
cargo upgrade -p [email protected]
Produces similar output, nothing is done to parse-display, no explanation why. It's the same version as currently in use, I would expect to see something like "nothing to do about parse-display" and less about ignored stuff I didn't ask to update.
Running this
cargo upgrade -p [email protected]
produces an error
Error: failed to lock to precise version
Caused by:
error: cannot specify both aggressive and precise simultaneously
but also updates Cargo.toml and Cargo.lock files.
The error message seems confusing, same as "both aggressive and precise". If something fails - I would expect it to fail without changing anything.
Running this
cargo upgrade -p [email protected]
produces this
As a reminder, you're using offline mode (--offline) which can sometimes cause surprising resolution failures, if this error is too confusing you may wish to retry without the offline flag.
(0.9.0 does not exist), but error message is strange - as an end user I'm not using offline mode.
crate roots 0.0.7 is installed, 0.0.8 is available
Running this
cargo upgrade -p [email protected]
updates roots to 0.0.8 as well as a few screens worth of semver compatible crates.
Interestingly output contains both
Updating mio v0.8.4 -> v0.8.5
and
excluded: anyhow, approx, ... mint, mio, ....
^ there's multiple versions of mio
When doing semver incompatible changes I would expect to update only them or things that are strictly required. When there's multiple versions of crates both being updated and not updated - it should be more explicit about what was updated and what wasn't.
When doing semver incompatible changes I would expect to update only them or things that are strictly required. When there's multiple versions of crates both being updated and not updated - it should be more explicit about what was updated and what wasn't.
Yes, I have been considering pulling out the recursive flag and making that based on whether compatible upgrades are being done.
Looking at this further, I think this needs to be split into separate issues. As a hint, if you can't give a specific title, than it likely is including too many things (like with commit messages). Having multiple things in one issue makes it harder to track the conversation and work and puts an extra burden on me as the maintainer. Without being split, the cost of these issues ends up being greater than they are worth and I tend to close them.