-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
nightly
-only options in ~/.cargo/config.toml
break build of default setup
#66
Comments
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 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 :) |
I would say it's more unexpected that you can't configure your project's local toolchain any more with The usefullness of this can't be overstated. Want to use unstable feature (e.g. 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 What your setting does is that it injects nightly flag to every cargo invocation. |
I was mainly referring to this:
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 Furthermore, 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 In this case however, I need to fork the resp. dependency and edit the That reminds me of dependency management in my C++ days. I guess I'm saying: there are quite a few well-founded reasons why |
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 |
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
Does that make sense? |
rust |
That's another good point why the idea of enforcing/assuming |
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
:The text was updated successfully, but these errors were encountered: