`nightly`-only options in `~/.cargo/config.toml` break build of default setup about cargokit HOT 12 OPEN

I don't think there's solution to this right now. Cargokit takes care of installing whichever toolchain the package requires. Your config basically breaks stable toolchain, which is not expected. Not sure what the best way of handling this would be.

from cargokit.

Fixed with an edit to one of the answers in the other issue. Kindly pardon the noise.

TLDR; I added rust/cargokit.yaml to the project generated by flutter_rust_bridge_codegen create:

 cargo:
  debug:
    toolchain: nightly
  release:
    toolchain: nightly 

from cargokit.

Right. That will work if you're in charge of the package. But if you're using somebody else's package that might still be trying to get build with stable.

from cargokit.

That is a severe limitation.

from cargokit.

Well, the config file basically breaks stable toolchain. It's a bit unexpected :)

from cargokit.

Well, the config file basically breaks stable toolchain. It's a bit unexpected :)

I would say it's more unexpected that you can't configure your project's local toolchain any more with rustup.

The usefullness of this can't be overstated. Want to use unstable feature (e.g. let chains)? Use nightly. Hit a compiler bug with latest nightly? Lock the toolchain to a previous last-known-good version by date. Etc.

This often includes stuff triggere/required by dependencies.

Not having control over this is just a bummer. And I mean that in a very caring way.

from cargokit.

If you want to use certain feature that means you are in charge of the code. For that you can use cargokit.yaml to force the plugin to compile with nightly. The idea here is that plugin author knows best which toolchain the plugin needs to build.

What your setting does is that it injects nightly flag to every cargo invocation.

from cargokit.

I was mainly referring to this:

Right. That will work if you're in charge of the package. But if you're using somebody else's package that might still be trying to get build with stable.

Rust developers are used to control exactly what tool chain gets used to compile anything Rust, including dependencies they aren't the author of.

Maybe I misunderstand but I read this as: if you use cargokit, this assumption does not hold any more.

Furthermore, rustup override is called override for a reason. It overrides the default.

The 'certain feature' was an example. There are other reasons to force a specific toolchain version.

Consider this case instead: package I don't maintain but depend on uses nightly and breaks (compiler bug). In a normal Rust project I can force the toolchain to something that allows me to keep working. Uninterrupted, apart from the time it takes to d/l the resp. toolchain.

In this case however, I need to fork the resp. dependency and edit the cargokit.yaml of that dependency. And remember that ofc.

That reminds me of dependency management in my C++ days.

I guess I'm saying: there are quite a few well-founded reasons why rustup works the way it does. Not just the two I brought up OTOMH here.

from cargokit.

Cargokit is primary meant to be used for plugin creators to write plugins in Rust that seamlessly build as part of Flutter build process. The assumption is that vast majority of target users might not even know what a toolchain is. In which case Cargokit will configure the toolchains, targets and choose the default toolchain depending on what each plugin requires.

It doesn't take into account that user have global rustc flags set that break stable rust. You have a situation on your machine where rustup run stable <anything> fails, which is not expected. If you have a proposed solution that will make this work while letting plugin authors specify which toolchain to use I'll be interested to hear about it.

from cargokit.

If you have a proposed solution that will make this work while letting plugin authors specify which toolchain to use I'll be interested to hear about it.

It's tricky because the idea that the toolchain is specified for a dependency and the user of the dependency has no way to override that (w/o jumping through aforementioned hoops) is kinda weird for Rust folk.

But since there is one explicitly specified, in cargokit.yaml, I would go for an in-between solutiuon. One that doesn't break/change what you have at the moment but allows people like me to override. Specifically:

1. Read ~/.rustup/settings.toml.

2. If the toolchain specified in default_toolchain differs from the one used for the current project or any dependency, print a warning like:

   Using Rust toolchain `stable` from `cargokit.yaml` but active default toolchain from `rustup` is `stable-2023-12-31`
   

   This will already make what happend to me with my cargo config's nightly-only flags less of a surprise. And contains a hint where to change this.

   Or for a dependency:

   Using Rust toolchain `beta` from `cargokit.yaml` for depdendency `foo` but active default toolchain from `rustup` is `stable-2023-12-31`
   

3. If the current project is specified in the [overrides] section of ~/.rustup/settings.toml, read this as: "the user really wants an overrride" and use it, i.e. ignore whatever toolchains any cargokit.yamls (incl. dependencies) this project depends on contains.

   Also print a warning like:

   Using Rust toolchain override `nightly-2024-04-01` from `rustup` and ignoring any toolchains set via `cargokit.yaml` for this project and all dependencies.
   

Does that make sense?

from cargokit.

rust stable on one machine may not be the same stable on another.

from cargokit.

That's another good point why the idea of enforcing/assuming stable, as cargokit currently does, is fundamentally flawed.

from cargokit.