To answer your question, I believe we should be supporting Python users. For many users, that means helping them to not be integrators. For some, it means helping them to do a simplified integration job. For all users, it means giving them an easy way of determining how they should get Python in a form that meets their specific needs.
-
For users who want to be their own integrator, give them good building blocks. I see wheels in this role - they let you do the integration at the “Python package” level, without needing to get involved with C ABIs, etc. It’s not a complete solution, and for some users wheels aren’t sufficent (because the ABI type problems are too complex) but to give an example, a “good enough” numpy wheel suits this type of user just fine.
-
For users who don’t want to be an integrator, we should both support existing integrators, and encourage the emergence of additional integrators where there are gaps in the coverage (for example, Windows users for whom conda isn’t the right solution).
-
I don’t think the “sole integrator” solution is the right approach. If the SC wanted the core team to be totally involved in packaging, then maybe it would be, but not with the current model where core development and packaging are independent.
But the message we’re hearing from users is “there are too many options”. Too many integrators is just another variation of “too many options”. We see this already in instructions on how to install a given library - which typically only cover pip, leaving everything else to “you’re on your own”[1]. And it’s also implicit in the confustion over “how do I get Python?”
So if we do want to support integrators, we need those integrators to work with us on simplifying the end user picture. A better starting page on python.org leading users through the process of deciding how to get Python, and what integrator to choose, if they want one. A common install[2] command - either implemented in core Python with “hooks” for integrators to link to their own implementations, or a defined command like pyinstall which all integrators are required to implement with the same interface, so that the user experience is identical. Or maybe something else - I don’t know what options would work. The PyPA could develop an implementation of pyinstall for wheel-based “user wants to be their own integrator” situations.
Or in some cases cover just conda, and leave non-conda users on their own. ↩︎
Possibly more than install - something more like Rust’s cargo is what I get the impression users actually want, but it may be too big of an ask to expect all integrators to buy into a common complete cargo-style interface. ↩︎