Shall the project be named "cargo-install-update" instead of "cargo-update"?

[vi]

I though for a moment this is the project backing cargo update command.

Shall each cargo subcommand project be named cargo-<name_of_the_subcommand>?

[nabijaczleweli]

Shall each? Don't know, don't care, I'm not a legislative body.

cargo update is a cargo builtin.

The closest thing to a "project" in this repository is the Cargo package, which is unrenameable.
The repository name, while changeable, would introduce unwieldy inconsistencies across the nomenclatural field.

Also: the "project" is rightly named "cargo-update" as it provides facilities for managing updates to cargo-installed executable crates. The installable executable example had to've been named cargo-install-update for compat reasons. (This also calls back to the #50 debate.)

[Celti]

Personally, having install-update be the subcommand has always irked me a bit — I can't think of any other hyphenated subcommands in the ecosystem, off the top of my head.

If we want to be renaming things anyway, I'd suggest stripping it back down to a single word, such as upgrade (a synonym for update) or reinstall (which succinctly ties it to the original cargo install while still suggesting its function).

If that's not in the cards... why upset the status quo? cargo-update vs cargo-install-update is by no means the only disconnect of naming in the crates ecosystem.

[nabijaczleweli]

Multiverbial subcommands certainly do exist – consider cargo-local-registry, cargo-edit-locally, or cargo-build-deps.
That they're rarer? Quite probably a byproduct of single words usually sufficing, though I do agree that cargo install-update's quite a mouthful (typeful?).

cargo-reinstall is already a thing (not that it matters, since cargo-update does much more than reinstalling things).
As for "upgrade", well, I don't feel like it can be parsed equivalently to "update" in the general case? The former ups the grade (i.e. the "degree of quality"), whereas the latter only the date (i.e. release time) of the software. The latter we can (mostly) guarantee, the former we can not. Also idk I'd be pretty confused by "update", "upgrade", and "upgrade-config" all existing at once.

Not that any of that matters at all, anyway, since the crate is irrenameable, and policy forbids renaming repositories (chiefly because things work in Very Fun And Consistent Ways™ when you do that).
And tbh it's good to see someone agree that the nomenclatural disconnect is not all that crazy. It sure as hell felt like I was losing my mind (more than usual, anyway) on this; so, thanks.

[ctsrc]

Speaking of names that collide, if this project were renamed to cargo-upgrade and installed its binary as cargo-upgrade then that would collide with the cargo-upgrade binary installed by cargo-edit.

https://github.com/killercup/cargo-edit

But on the subject of renaming, I was a little bit confused when I first came across this project after searching on Google for a way to upgrade installed binaries, because the name cargo-update suggested to me that it would collide with the builtin update command of cargo. Of course, as soon as I read the README I learned that this was not the case and that I could install and use your command without such concern :)

But if you ever did decide to rename the crate then I think renaming the crate to cargo-install-update to reflect the name of the installed binary would make sense. Though I see your reason for not wanting to rename the crate. Just mentioning it since you've kept the issue open which suggests to me that maybe you are still considering renaming it?

[nabijaczleweli]

I mean, by policy, unless there's at least an Important Reason:tm: to, I don't rename anything. By external (Crates.io) policy, I can't rename the crate. By compat, I cannot change the exec name because I deployed it once already,
Anyway, point is: I can't re-name anything without fucking something (else) up, so I won't, fact of the matter is.

And the issue's still open because the OP didn't close it and I haven't heard back from them, so it just felt kinda rude/incorrect to, I guess?

[vi]

Maybe there can be something like alias or forwarder, so cargo install cargo-install-update means the same as cargo install cargo-update?

[nabijaczleweli]

That's something to be taken up with the cargo team and not me

[vi]

I means publishing a new crate cargo-install-update with pub use cargo_update::main;

[nabijaczleweli]

Yeah, nah, I'm not maintaining an additional crate that's just a wrapper.

I consider this subject matter to have been exhausted. Thank you all for participating!