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

cargo update silently doesn't update tokio-threadpool without --precise #7671

Open
glandium opened this issue Dec 6, 2019 · 1 comment
Open
Labels
A-dependency-resolution Area: dependency resolution and the resolver C-bug Category: bug Command-update S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.

Comments

@glandium
Copy link
Contributor

glandium commented Dec 6, 2019

Problem
I was trying to update tokio-threadpool in Firefox, and had a hard time with it, especially because cargo update would say absolutely nothing.

Reduced Steps

  1. cargo new foo
  2. Edit foo/Cargo.toml to add:
[dependencies]
hyper = "=0.12.19"
tokio-threadpool = "=0.1.14"
tokio-executor = "=0.1.7"
  1. Enter the foo directory and run cargo update. This gives us the initial state for Cargo.lock.
  2. Remove the tokio-threadpool and thread-executor dependencies in Cargo.toml
  3. Run cargo update -p tokio-threadpool

Nothing happens, and the output is desperately empty.

Possible Solution(s)

cargo update -p tokio-threadpool --precise 0.1.17 (0.1.17 being the last version as of writing) works, and updates both tokio-threadpool and tokio-executor. I think cargo update -p tokio-threadpool should work just as well.

If not, then at least, cargo should say something about the fact that there is a newer version, but it can't be used because $reason, similar to what happens after upgrading both tokio-threadpool and tokio-executor, and trying to downgrade tokio-executor with cargo update -p tokio-executor --precise 0.1.7:

error: failed to select a version for the requirement `tokio-executor = "^0.1.8"`
  candidate versions found which didn't match: 0.1.7
  location searched: crates.io index
required by package `tokio-threadpool v0.1.17`
    ... which is depended on by `hyper v0.12.19`
    ... which is depended on by `foo v0.1.0 (/tmp/foo)`
@glandium glandium added the C-bug Category: bug label Dec 6, 2019
rnestler added a commit to rnestler/reboot-arch-btw that referenced this issue Oct 12, 2021
This was done using `cargo update zbus --precise=1.9.2`, since `cargo
update` did only update to 1.9.1.

Also note that now runing `cargo update` will *downgrade* zbus again to 1.9.1:

    % cargo update
	Updating crates.io index
	Updating bitflags v1.2.1 -> v1.3.2
	  Adding cfg-if v0.1.10
	Removing memoffset v0.6.4
	Updating nix v0.20.2 -> v0.17.0
	  Adding void v1.0.2
	Updating zbus v1.9.2 -> v1.9.1
	Updating zbus_macros v1.9.2 -> v1.9.1

See also the following cargo issues:
 * rust-lang/cargo#7671
 * rust-lang/cargo#5702
rnestler added a commit to rnestler/reboot-arch-btw that referenced this issue Oct 12, 2021
This was done using `cargo update zbus --precise=1.9.2`, since `cargo
update` did only update to 1.9.1.

Also note that now runing `cargo update` will *downgrade* zbus again to 1.9.1:

    % cargo update
	Updating crates.io index
	Updating bitflags v1.2.1 -> v1.3.2
	  Adding cfg-if v0.1.10
	Removing memoffset v0.6.4
	Updating nix v0.20.2 -> v0.17.0
	  Adding void v1.0.2
	Updating zbus v1.9.2 -> v1.9.1
	Updating zbus_macros v1.9.2 -> v1.9.1

See also the following cargo issues:
 * rust-lang/cargo#7671
 * rust-lang/cargo#5702
@epage epage added the A-dependency-resolution Area: dependency resolution and the resolver label Nov 3, 2023
@epage
Copy link
Contributor

epage commented Nov 3, 2023

When you use --package, cargo tries to only update that one package and locks down all dependent packages. I'm surprised --precise works.

As for letting people know why an upgrade didn't happen, #7167 something similar.

@epage epage added the S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted. label Nov 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-dependency-resolution Area: dependency resolution and the resolver C-bug Category: bug Command-update S-needs-design Status: Needs someone to work further on the design for the feature or fix. NOT YET accepted.
Projects
None yet
Development

No branches or pull requests

3 participants