Deprecated binary leads to update loop.

nabijaczleweli / cargo-update

A cargo subcommand for checking and applying updates to installed executables

MIT License

1.22k stars 42 forks source link

Deprecated binary leads to update loop. #44

Closed letheed closed 7 years ago

letheed commented 7 years ago

cargo-edit released v0.2.0 following v0.1.6. The new version deprecates the binary cargo-list. So .crates.toml now contains:

"cargo-edit 0.1.6 (registry+https://github.com/rust-lang/crates.io-index)" = ["cargo-list"]
"cargo-edit 0.2.0 (registry+https://github.com/rust-lang/crates.io-index)" = ["cargo-add", "cargo-rm", "cargo-upgrade"]

which if I run cargo install-update -al leads to:

Package         Installed  Latest    Needs update
cargo-edit      v0.1.6     v0.2.0    Yes
cargo-edit      v0.2.0     v0.2.0    No

cargo install-update cargo-edit will compile and install cargo-edit v0.2.0 again and again instead of saying No packages need updating..

nabijaczleweli commented 7 years ago

What do you mean by "deprecates"? It looks to me like you have two versions installed, which is handled as one would expect. I mean, unique()ing on max() is a pretty simple fix, but... idk, something doesn't feel right about this.

letheed commented 7 years ago

I mean cargo-edit 0.1.6 provided ["cargo-add", "cargo-list", "cargo-rm"]. cargo-edit 0.2.0 provides ["cargo-add", "cargo-rm", "cargo-upgrade"].

The first problem is that cargo install-update -al now says that cargo-edit "needs update" although I just ran cargo install-update cargo-edit and v0.2.0 is already installed.
The second problem is that if I run cargo install-update cargo-edit again it will compile and install v0.2.0 again even though it isn't needed because we're already up-to-date.

nabijaczleweli commented 7 years ago

So you have two versions of cargo-edit? Did that happen naturally or how did you do that?

From the "business logic" standpoint that behaviour is correct – cargo-edit-v0.1.6 needs to update to cargo-edit-v0.2.0, but specialcasing "there's two versions of the same thing for some reason" to "there's one with max() version" might make sense.

letheed commented 7 years ago

Well I had cargo-edit 0.1.6 installed. I updated it with cargo install-update cargo-edit.

cargo-list was not removed automatically, and so now .crates.toml ends up listing both versions side by side.

letheed commented 7 years ago

I don't really have both version installed at the same time, because cargo-add and cargo-rm are from 0.2.0. So they are not necessarily compatible with 0.1.6.

nabijaczleweli commented 7 years ago

That's weird, that'd mean that cargo install -f cargo-edit didn't remove the old one, which would make this a cargo bug (or feature).

I'll make a specialcase for this, sure.

letheed commented 7 years ago

Yeah, I'm honestly not sure whether this is a cargo bug or if this is the expected behavior.

Thanks!

nabijaczleweli commented 7 years ago

Were I you, I'd pop an issue over at https://github.com/rust-lang/cargo either way.

letheed commented 7 years ago

Yeah, I'll go ask over there.

letheed commented 7 years ago

Cargo issue: https://github.com/rust-lang/cargo/issues/4321

nabijaczleweli commented 7 years ago

BTW it's cargo install-update not cargo update-installed

nabijaczleweli commented 7 years ago

Can you try if current master works for you (it does for me, but you never know)? Will release if so.

letheed commented 7 years ago

Yeah, I edited my msg. Sorry, I haven't slept in two days. -__-

Sure I'll do that.

letheed commented 7 years ago

It's all good for me.

nabijaczleweli commented 7 years ago

Released in v1.1.2