2 ms·

It is a rust dev cultural problem that will go away with time and general adoption. Right now almost all people writing in rust are the bleeding edge types that

It is a rust dev cultural problem that will go away with time and general adoption. Right now almost all people writing in rust are the bleeding edge types that use the latest backwards incompatible features without caring. Combined with these new features being added every couple of months it is almost required to use insecure rustc installation from outside your repos no matter the distro. 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.

steveklabnik 5y ago
Our surveys show that most users use stable rust, with few using exclusively nightly. The issue here isn’t about backwards compatibility, it’s about forward compatibility.
- Macha 5y ago
  Isn't this a matter of perspective? The older Rust compiler is not forwards compatible with the new project. The newer project is not backwards compatible with older Rust compilers
  - deleted 5y ago
    [deleted]
  - steveklabnik 5y ago
    Compatibility is a property of two releases, and it is usually discussed in the context of the API you provide to consumers. It's Rust that's providing APIs here, not the projects themselves. Either way, the parent is talking about Rust here, so that's the perspective being shown.
busterarm 5y ago
> It is a rust dev cultural problem that will go away with time and general adoption. Right now almost all people writing in rust are the bleeding edge types that use the latest backwards incompatible features without caring. Combined with these new features being added every couple of months it is almost required to use insecure rustc installation from outside your repos no matter the distro. 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.
- Macha 5y ago
  > 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 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 https://pypi.org/project/cryptography/#files [2]: e.g. for the oldest supported ubuntu version https://packages.ubuntu.com/bionic/python-cryptography https://packages.ubuntu.com/bionic/python-cryptography
  - busterarm 5y ago
    At the time (back in february or so) it was to use, before a change was made to use a built version of the library. Pip did not have prebuilt wheels at first. It is just to build as you said _now_. 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.

steveklabnik 5y ago

Our surveys show that most users use stable rust, with few using exclusively nightly. The issue here isn’t about backwards compatibility, it’s about forward compatibility.

Macha 5y ago
Isn't this a matter of perspective? The older Rust compiler is not forwards compatible with the new project. The newer project is not backwards compatible with older Rust compilers
- deleted 5y ago
  [deleted]
- steveklabnik 5y ago
  Compatibility is a property of two releases, and it is usually discussed in the context of the API you provide to consumers. It's Rust that's providing APIs here, not the projects themselves. Either way, the parent is talking about Rust here, so that's the perspective being shown.

busterarm 5y ago

> It is a rust dev cultural problem that will go away with time and general adoption. Right now almost all people writing in rust are the bleeding edge types that use the latest backwards incompatible features without caring. Combined with these new features being added every couple of months it is almost required to use insecure rustc installation from outside your repos no matter the distro. 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.

Macha 5y ago
> 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 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 https://pypi.org/project/cryptography/#files [2]: e.g. for the oldest supported ubuntu version https://packages.ubuntu.com/bionic/python-cryptography https://packages.ubuntu.com/bionic/python-cryptography
- busterarm 5y ago
  At the time (back in february or so) it was to use, before a change was made to use a built version of the library. Pip did not have prebuilt wheels at first. It is just to build as you said _now_. 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.