Hello and thanks for the work that's gone into this and @llvm, truly appreciated 馃檹
I have now come across this issue multiple times and I'd like to get your opinion before proposing a fix either here or on the affected modules in the BCR.
Essentially, the issue is that if multiple modules have the following declaration in their MODULE.bazel:
toolchains = use_extension("@rules_rs//rs/toolchains:module_extension.bzl", "toolchains")
toolchains.toolchain(
edition = [edition],
version = [version],
)
use_repo(toolchains, "default_rust_toolchains")
register_toolchains(
"@default_rust_toolchains//...",
)And if [edition] or [version] is different in any of these modules (or in the main module compared to its dependencies), then we get the following error:
(06:22:37) ERROR: [cache]/external/rules_rs+/rs/toolchains/module_extension.bzl:443:17: Traceback (most recent call last):
File "[cache]/external/rules_rs+/rs/toolchains/module_extension.bzl", line 443, column 17, in _toolchains_impl
fail("Toolchain repo {} has conflicting tag configurations".format(repo_name))
Error in fail: Toolchain repo default_rust_toolchains has conflicting tag configurations
As the adoption of rules_rs grows, I believe this situation is unfortunately more and more likely to arise.
One possible fix (as done in aspect-build/rules_lint#998) is to remove the toolchain call but this requires patching the modules one by one and there might be cases where a module actually requires a version/edition that's higher than the default of rules_rs.
Another possibility would be to mark the extension + register_toolchains as dev dependencies but I think it would be problematic when the main module brings in a dependency that needs rules_rs without bringing rules_rs (zenoh-c is a good example here, it provides a C library which can be consumed without needing a rust toolchain explicitly declared in the main module)
Overall, I think the better solution is to reconcile the conflicting version within rules_rs:
- if the tag comes from the main module, this version wins (this feels the least surprising to consumers imho)
- otherwise the highest version and highest edition wins
But maybe there's another way I'm not thinking about or a good reason for not doing that in the first place.
Hello and thanks for the work that's gone into this and
@llvm, truly appreciated 馃檹I have now come across this issue multiple times and I'd like to get your opinion before proposing a fix either here or on the affected modules in the BCR.
Essentially, the issue is that if multiple modules have the following declaration in their
MODULE.bazel:And if
[edition]or[version]is different in any of these modules (or in the main module compared to its dependencies), then we get the following error:As the adoption of rules_rs grows, I believe this situation is unfortunately more and more likely to arise.
One possible fix (as done in aspect-build/rules_lint#998) is to remove the
toolchaincall but this requires patching the modules one by one and there might be cases where a module actually requires a version/edition that's higher than the default of rules_rs.Another possibility would be to mark the extension + register_toolchains as dev dependencies but I think it would be problematic when the main module brings in a dependency that needs rules_rs without bringing rules_rs (zenoh-c is a good example here, it provides a C library which can be consumed without needing a rust toolchain explicitly declared in the main module)
Overall, I think the better solution is to reconcile the conflicting version within rules_rs:
But maybe there's another way I'm not thinking about or a good reason for not doing that in the first place.