Toolchain and options settings for each crate

[lo48576]

I usually install crates using stable rustc (and stable cargo), but I want some packages to be built and installed with nightly rustc.
In my case, clippy (and diesel_cli in the past) should be (and can only be) built with nightly rustc and cargo.
Additionally, I installed diesel_cli with cargo option --no-default-features --features="sqlite".

Is there any plan to add features (or how-to) to use different toolchains (and build options) for each crate?

[nabijaczleweli]

Is there any plan

Not really, but mostly because there exist no mechanisms that save that kind of data so I can't reuse it => I'ven't considered reusing it.

I've considered the idea, but very briefly, since it'd drastically increase complexity for something that, I reasoned, was a fringe case.

This would effectively entail manual editing of TOMLs somewhere alongside the other cargo files (and positioning of those is a bloody disaster as is).

TL;DR: Possible? Ya. Viable? Probably. Usable? Not really.

But maybe you have a brilliant idea:tm: that can make this reasonably OK?

[lo48576]

I agree that manual editing of TOML should be avoided.
But in this case, it can be avoided with adding a new subcommand to cargo-install-update.

For example (assume the new subcommand to be option):

• cargo install-update option set diesel_cli '--no-default-features --features-sqlite' will save diesel_cli = { cargo_option = "--no-default-features --features-sqlite" } TOML data to somewhere.
• cargo install-update option set clippy nightly will save clippy = { toolchain = "nightly" } TOML data to somewhere.

This is similar to rustup override's way to sets toolchain for some project (and use default for others).

"Somewhere" might be [cargo-update] section of $CARGO_HOME/config (like cargo-shell does), cargo-update's own setting file, or somewhere else (the config toml path can be passed as command-line option or envvar).

This idea surely makes cargo-update more complex, so I can't contradict if you say this change is complex enough...

[nabijaczleweli]

Imma try to make something workable then I guess

[nabijaczleweli]

Okay, so it works on my machine:tm:, but it'd be cool if you could test it from master

[lo48576]

I used current master (d23e30c) and it worked as I wanted!

I noticed these points can be more better:

• cargo install-update-config -h shows usage cargo install-update-config [OPTIONS] <PACKAGE>, but cargo install-update-config -f sqlite diesel_cli shows cargo install-update-config <PACKAGE> --feature <FEATURE>....
  These are inconsistent (and --feature only works with the latter form).
• cargo install-update only do update, doesn't do install. So at first it needs running cargo install diesel_cli --no-default-features --features "sqlite" when diesel_cli is not installed, in spite of my setting config for cargo-install-update.
  If cargo-install-update had "force install (even if it is not installed yet)" option, it will be very convenient.
  (I think that saving and applying cargo option might be what cargo install should do and it is not business of cargo-install-update, but I will be happy if install and update can be done by the same command.)

Anyway, this feature helps me a lot. Thank you so much for your great work!!

[nabijaczleweli]

Re: option ordering -- I thought it'd have something to have with the order I specified them with, but it doesn't, it's just clap's thing, apparently.

Re: installing -- I'll see what I can do

[nabijaczleweli]

There's a --allow-no-update option that does exactly what you've asked of it so if you're satisfied with it I can flesh out the docs&shit and release it

[lo48576]

Yes, this is good, but it might be better if there is short option for it...

[nabijaczleweli]

Added -i as short therefor, then.

[lo48576]

Thank you, this is what I wanted! 😄

[nabijaczleweli]

Released in v0.8.0