This remains my most fundamental reason for preferring manylinux2014 over perennial manylinux.
Notwithstanding @njs’s comments that “we actually have an implementation defined standard” right now, what we do have right now, and in manylinux2014 we will continue to have, is a documented set of rules stating what it means to conform to the relevant spec. I don’t buy the argument that “if auditwheel says one thing and the PEP says another, the PEP is wrong”. The reality is that it’s OK for the PEP to need updating, and it’s OK for the updates to not get done in a timely manner - people are human - but you don’t need to read the code of auditwheel to know what the standard is. If you write something that satisfies the standard, and auditwheel rejects it, you can raise the issue and have a debate about whether the standard needs updating, but you can reasonably start from the presumption that the standard is what you work to.
The perennial manylinux spec abandons that and says that you must use auditwheel. And that auditwheel’s word is final - even if you don’t understand why auditwheel says what it does. That is, to me, fundamentally the definition of “implementation defined behaviour”.
I see the practical benefits of not needing a new PEP and an installer change each time we want an updated baseline. And I can see that for people doing the actual grunt work of building wheels, all of this may be irrelevant in practice. But I think there is value in having standards that an outsider (like myself!) can point to and say, “I don’t understand the details here, but I can see that this is a cleanly defined and implementable definition of what’s required”.
So right now, I feel the onus is strongly on the supporters of perennial manylinux to address the concern about “implementation defined behaviour”, not by saying that it doesn’t matter, but by providing a definition of the behaviour that’s external to the implementation. If the PEP process is too onerous, then that definition can be in a spec that is managed and change controlled by a different process, but it should be available somewhere. (At the end of the day, I’m surprised if anyone thinks that a piece of code as complicated as auditwheel should be managed without a written spec - all I’m asking is that if the spec will no longer be managed via PEPs, what is the proposal for managing it in future?)
I don’t actually see any other discussion happening here. The two proposals have been put out there, and there’s mostly silence. So I’m inclined to say that there’s no consensus to be reached here, we’re just looking at a straight choice between two proposals, and it’s ultimately going to be down to me to make that choice. So let’s hear the arguments, and when they die down I’ll take that as a signal that everyone’s ready for a final decision to be made.
(However, if there’s any significant work going on “behind the scenes” that means there is need for further discussion and a realistic chance of a merged compromise proposal, then someone speak up. I’m not trying to shut down discussion here, merely avoid an extended “so what do we do next?” period).
And as background for me, if someone could point me at some instructions on how I, as a package developer working mostly on Windows, would take a package of mine and build manylinux binaries for it, that would be really helpful. I’m aware that I’m coming from this with knowledge that’s mostly focused on the “packaging tool” perspective, and I’d like to balance that with some “project maintainer” understanding. Thanks.
It doesn’t seem that bad. There’s