A user in gitter asked:

I have a bin crate using gnat_arm_elf = "^11.2" and it depends on other crate that also have similar dep. I would really like to be able to use gcc 12 (for the 2022 support). How can I do that?

And the answer is that there's no easy way. A compiler pin won't readily work (although we could fix that, and it makes sense for orthogonality) because of how the compiler toolchain is being handled. Still, that would require knowing the compiler location inside Alire's cache, or having a separate installation, so all in all not super friendly. So as of today you need to get the offending crates locally, edit their manifests, and pin to them locally.

This highlights a problem/need that will arise as more compilers are released: a crate depending on a major compiler version will hold back the compiler for everything. So, an easy way to at least locally test higher compilers could be useful. And the same applies to regular crates as they get more releases (although here the problem is lessened by regular pins already working).

The obvious possibility is doing it through the existing version pins. A version pin currently allows to force a crate version, but it won't allow to use a version that's outside dependencies (because these were originally designed to freeze dependencies to a concrete version, but not override them). So I see two evident possibilities here:

1. Change version pins to override the dependency versions by default.
2. Add a new override/force property to version pins, e.g. something like crate = { version = "x.x" override = true }

I lend to 2) so as not to change existing behavior, and make explicit that we do want to go out of bounds. But it may be more in line with user expectations that pins by default are overriding, just like path/url pins are.