What do you want in Python packaging's future governance model?

[abravalheri (Anderson Bravalheri)]

Change: When creating standards/tools:

• avoid^[1] breaking people’s existing workflow.
• avoid^[1:1] telling people that they should change their workflow because it is no longer supported (or is no longer “the default”, or is no longer “the recommended”).

The following posts from Paul do a much better job in describing the challenge then my summary above:

Python Packaging Strategy Discussion - Part 1

(I’m a maintainer of pip). I agree wholeheartedly with this. And I’d go further and say that for such a tool to be successful, it will be at least as important to decide what workflows we won’t support, as what we will. The lesson we have learned from pip is that if you try to support everything that people come up with, you’ll end up in a mess. And of course, the big problem here will be that many of the respondents wanting a unified tool will have been making an implicit assumption that thei…

Python Packaging Strategy Discussion - Part 1

That’s not what I was saying. I was specifically talking about support of workflows, not of use cases. So, in particular, I am absolutely not in favour of declaring any groups of users or parts of the ecosystem as “out of scope”. I do expect that we may need to ask users to do things in certain ways in order to address their use cases, but I don’t see why that should be unacceptable - there needs to be compromise on both sides if we’re to create a single solution that works for everyone (which …

Right now users that responded the packaging survey seem to want a unified tool, but, as Paul puts in the comments highlighted above, they implicitly assume that an eventual unified tool will cover their workflow. We should refuse the temptation of cutting things (that currently work) out of the scope in order to achieve “ecosystem simplification” (even if the simplification is purely cognitive).

Effect: Avoid backlashes from the community.

---

1. I am using “avoid” intentionally because there might be cases which this cannot be avoided ↩︎ ↩︎