[Apparently] Needless Rust edition bump breaks build on Void Linux

[ahesford]

Bug Description

Is there a purpose for the edition bump in 4d51112? Void Linux is still working toward bumping rust and this makes it impossible to build maturin without reverting the edition change. Maturin compiles fine after reverting only the Cargo.toml edition spec.

Void has rust 1.53.0, which is less than six months old. The 2021 edition was declared stable in rust 1.56.0, released in late October. Unless it solves a real problem with maturin, making a one-month-stable edition a hard requirement seems undesirable.

Your Python version (python -V)

N/A

Your pip version (pip -V)

N/A

What bindings you're using

No response

Does cargo build work?

• Yes, it works

If on windows, have you checked that you aren't accidentally using unix path (those with the forward slash /)?

• Yes

Steps to Reproduce

1. Try to build maturin 0.12.* with rust 1.53.0.
2. Cry to the heavens about the insanity of the rust ecosystem.

[messense]

Thanks for opening the issue.

We don't have a MSRV policy yet since most of our users use pre-built wheels from PyPI and package managers like Homebrew, conda and Alpine Linux updates their Rust version frequently.

To establish a working MSRV policy for Void and other distributions, can you propose some requirements?

[konstin]

Imo maturin only supports the latest stable rust, other rust versions are unsupported by the rust team anyway. Please install rust through rustup, the official installer.

[ahesford]

"Supporting" and "requiring" are two very different things. I don't have a good proposal for what it means to support past versions because I don't really follow rust evolution. Maturin is packaged in Void to support the python3-adblock package.

However, it seems that there is no harm in delaying edition bumps until new features are actually used, especially since the default (official) behavior when the edition is unspecified is to assume an edition that is several years old.

[cinerea0]

Please install rust through rustup, the official installer.

This is not how packages are built and distributed for Linux distros.

[messense]

However, it seems that there is no harm in delaying edition bumps until new features are actually used, especially since the default (official) behavior when the edition is unspecified is to assume an edition that is several years old.

I'm fine with revert back to 2018 edition, we can do that in the next release.

This is not how packages are built and distributed for Linux distros.

I'm all for making maturin available on more platforms so please elaborate.

BTW, it'd be nice if distro packagers can send patches to upstream if possible, for example this one (add-ppc-tier3.patch) void-linux/void-packages@901a121#diff-c84f974ff650f9eb01dff5cffb60667298de1b7bd15f9a1d9f666efa8cc760f7

[ericonr]

I'm fine with revert back to 2018 edition, we can do that in the next release.

Thanks, appreciated!

I'm all for making maturin available on more platforms so please elaborate.

Distributions (and most of their users who only want to compile software, rather than develop) will use the distro's packaged toolchains instead of something provided by an external tool. It has many benefits, including: better integration with the system, any necessary patches for that specific system organization or runtime differences, and a previously established chain of trust.

Important patches can include:

• unbundling Rust's treatment of musl as a static-only target so things are guaranteed to work correctly
• arch differences (for example, Void Linux uses ELFv2 ABI for all powerpc64 targets, which isn't what mainline Rust defines - this is a distribution choice and we deal with it, but that requires that our own toolchain be used for actually building things)

Furthermore, someone on an older Debian or Alpine system (say, a 3.14 Alpine system) can build the software with minimal hassle, if we don't require newly-released features. And they might have corporate policy that forbids usage of binary wheels straight from PYPI, for whatever reason.

BTW, it'd be nice if distro packagers can send patches to upstream if possible, for example this one (add-ppc-tier3.patch) void-linux/void-packages@901a121#diff-c84f974ff650f9eb01dff5cffb60667298de1b7bd15f9a1d9f666efa8cc760f7

FWIW, there's a good reason for this one. ppcle is an experimental target that is only recently supported by LLVM, definitely not explicitly supported by musl or glibc, support to run binaries compiled for it on Linux has only recently been merged; and it can only run in 32-bit compat mode on a 64-bit kernel, there isn't a native kernel for it.

That's a patch that I don't think should be upstreamed just yet.

[messense]

#710 shipped in v0.12.3.

[ericonr]

Awesome, thanks!!