Open virtualritz opened 2 months ago
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.
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
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.
That is a severe limitation.
Well, the config file basically breaks stable toolchain. It's a bit unexpected :)
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.
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.
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.
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.
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:
Read ~/.rustup/settings.toml
.
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`
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.yaml
s (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?
rust stable
on one machine may not be the same stable
on another.
That's another good point why the idea of enforcing/assuming stable
, as cargokit
currently does, is fundamentally flawed.
I reported an analogous issue with
flutter_rust_bridge
and was forwarded to here.Indeed, it seems it is caused by
cargokit
usingstable
even thoughnightly
is set as default on my system and I havenightly
-only options in my~/.cargo/config.toml
.TLDR; how can I tell
cargokit
to use anightly
toolchain?Output from
flutter run
:And output from
flutter run --verbose
: