Support non-manylinux Linux builds about maturin HOT 4 CLOSED

What is the usecase / advantage of having linux_x86_64 instead of manylinux1 builds?

from maturin.

If I build on an up to date Linux machine, apparently it breaks manylinux1 by linking a more recent glibc. It's also not unusual to vendor wheels for a project, where you may want to commit extensions compiled against your specific distro. It seems simpler and consistent with wheel's manylinux1 being a subset of platform-specific wheels to just let platform-specific wheels be built on Linux.

from maturin.

I forget the details, but I also had an issue building orjson on an Alpine (musl libc) container where it failed manylinux compliance. I see pyo3-pack distributes linked against musl, but also builds a binary? Not sure what that issue is. It would have helped to just build a cp37 wheel and been done, though.

from maturin.

Those sound like good reasons to support the non-manylinux tag. For the implementation I currently favour a --manylinux=[on|skip-auditwheel|off] option that deprecates the current --skip-auditwheel.

You can't build cpython libraries on alpine, because python itself uses glibc and so all extension modules need to use it, too. For pyo3-pack and other binaries this restriction does not apply because they don't need to be loaded by cpython.

from maturin.