Debian 11 was released a couple weeks ago and the rustc it ships with is already so out of date (7 months old, gasp!) software written for modern rust versions can't be compiled with it. And this isn't a Debian only problem.
I've certainly had issues with e.g. the Python or Node version being too outdated on Ubuntu, RHEL, CentOS etc. And when that happens, it's a bigger problem, as it's a runtime dependency, not just a build time one. It's the risk you sign up for picking a fixed release distro.
Consequently, if you're developing cutting edge software in those languages, you're probably running nvm, your favourite virtualenv wrapper (poetry, pipenv, pip-tools), or letting your IDE download a runtime for you. And yes, these tools are full of curl | bash or curl | python install instructions.
Bash actually gets new, backwards incompatible, features pretty often too but you never have to run a bash script in a container or some third party interpreter. Bash devs simply care about having their software be able to run on setups more than a handful of months old.
The issue here isn’t about backwards compatibility, it’s about forward compatibility.
The older Rust compiler is not forwards compatible with the new project.
The newer project is not backwards compatible with older Rust compilers
And yet at the same time the people working this way are pushing their changes out in a way that affects the rest of the world looking for stable repeatable systems.
There was a brief few weeks at the beginning of this year where pyca/cryptography had a hard dependency on a rust compiler being on the local system. pyca/cryptography is a dependency of a large number of important applications, notably Ansible.
You're fucking up my automation if you're expecting me to `curl <website> | sh` in my build pipelines. pyca/cryptography's maintainers were completely not understanding of the situation and derided anyone who criticized them for it along with statements like "I refuse to work in C++." Zero concern from them about breaking the world for lots of people.
To build. Not to use. Your ansible use case would be totally unaffected, as ansible can just pull the manylinux, Windows or Mac wheel from pypi [1] or the python{,3}-cryptography package from your repo[2]. The one major distro where you can't use the manylinux wheel if you decide to build yourself is Alpine, and Alpine packages a sufficiently modern Rust compiler to build the module since 3.12, released May 2020 so it's a non issue there. The last Alpine version without a sufficiently up to date Rust compiler, 3.11, goes out of support in 1.5 months.
This is not like an application depending on a specific Node or Python version, where it must be there at runtime. You can use Ansible with no rust compiler in your life.
Anyway, the current commit of python-cryptography requires Rust 1.41, from January 2020 in the latest commit. This is only two months newer than the required Python version (3.8, from October 2019) for the current commit of Ansible...
[1]: https://pypi.org/project/cryptography/#files
[2]: e.g. for the oldest supported ubuntu version https://packages.ubuntu.com/bionic/python-cryptography
There were several threads started about the situation at the time and I was also affected by it.
Ultimately the problem is really the shitshow that is Python packaging, but I'm not winning that battle at work anytime soon. There aren't really great replacements for Ansible out there.
That's not the only issue, however, as switching to Rust removed support for a number of niche platforms. pyca/cryptography is also a dependency for OpenWrt which runs on a number of these now-deprecated platforms.
But also, if you're using RHEL/CentOS, haven't you implicitly signed up to _not_ running the cutting edge software? You get what the vendor will support. That's the tradeoff you have chosen by picking such a distribution.
Yes, exactly. Meanwhile the Rust community, in its current fast-changing, cutting-edge state is doing its best to work itself into being a basic dependency for everything. In the name of safety.
It's psychopathic behavior.
I don't understand your complaint here. It feels like you want to have your cake and eat it. You want nobody else to use anything too new to be packaged in enterprise Linux repositories, yet you want freedom to use the latest versions of these software, despite having perfectly usable versions for your era of software packaged in that enterprise distro.
Rust is now an indirect dependency of ansible and you need to go outside the RHEL supported process to build the latest commit of ansible (or Firefox, or linkerd, or whatever) on your RHEL/CentOS 7 system. Or you could just use the RHEL supported version of ansible.
The current RHEL version (RHEL 8) even has Rust packages, in the same repository and level of trust as such famously cutting edge software as nginx, node and dotnet.
I'm not trying to have my cake and eat it to, I'm asking for package maintainers to use their fucking brains. pyca/cryptography only runs on Rust 1.41 now after efforts that were made to downgrade to a more stable/available/packaged Rust version.
And on the Rust community/leadership, urging everyone to use the bleeding new (curl rustup | sh) instead of stable packages is herding a bunch of lemmings who really should know better, professionally speaking, into building a world that is less maintainable than when they started.