Thanks @abravalheri for expressing that point of view. I have similar feelings around respecting maintainers time - both what they’ve done in the past, and what we may be asking of them in the future. And I think the standardization of metadata in pyproject.toml and of build interfaces (PEP 517 & co) is one of the success stories of Python packaging. No need to turn back on that one and aim for unification of build tools imho.
Overall I think we still are trying to figure out what is feasible and a good idea to unify, or not. The message from users is that the current state of things is still not great, and to please unify something - but it’s very much unclear what that something is.
@pradyunsg asked that question pretty explicitly. I’ll repeat it here, with my answers:
- Unification of PyPI/conda models → NO
- Unification of the consumer-facing tooling → NO
- Unification of the publisher-facing tooling → NO
- Unification of the workflow setups/tooling → YES
- Unification/Consistency in the deployment processes → NO
- Unification/Consistency in “Python” installation/management experience → NO
- Unification of the interface of tools → YES (as much as possible)
It’d be great to see others’ answers to this.
Regarding some of the other topics in this thread, I think they come in because there’s a number of inter-related things here. Because if you say something should be unified, you should at least have some level of confidence that it’s a good idea to pursue that unification and that there are no hard blockers.
I wrote a blog post with a comprehensive possible future direction, however the content in there all follows from a few things: the what to unify Qs above, Steve’s question on system integrators, and the assumption that major breaking changes have to be avoided. I’d really like to get a better sense of whether others have a similar understanding at this very highest level.