Python Packaging Strategy Discussion - Part 1

It’s very tempting to double down like that, because it broadly validates the previous direction and choices made in this space, rather than face the increasingly loud feedback that the outcomes[1] of those choices have produced a state of affairs that users are very unhappy with.

No-one is talking about making anything less capable. But I argue that overall we do want less tools doing the same thing (like build backends), rather than more. Tools want to be used, and in the case of build backends, those users are library authors[2], who pass on their choices to all downstream users[3], which just perpetuates the situation that is being criticised.

I’d say that people with roles like @steve.dower and @barry (absolutely requiring their own backends for internal BigCorp distributions) are an absolutely miniscule portion of users[4]. Those use cases are also those which will make things work regardless, because of BigCorp paying its employees to solve the (internal) problems at hand, but it’s not a great stand-in for the needs of the average user.

It’s been cited a lot of times in this thread already, but “write standards that allow people to tailor packaging to their needs, not force people into a model that doesn’t work for them” is just going to lead to more of the “XKCD: standards” type outcomes, rather than do any halfway meaningful consolidation[5].

It means that, despite people’s good intentions, the overwhelmingly dominant inertia[6] will all-but-ensure that everyone continues in their respective groove / niche / bubble, continues optimising for their own use cases and user base, and leaves the people farthest removed from these discussions with a wild zoo of tools to deal with (at least I strongly doubt that any new default without substantial weight behind it would make dent in this).

If that is the outcome of a 250+ post “strategy discussion” with the explicit aim to reduce this proliferation of tools, I’d be pretty disappointed.


  1. I’m distinguishing this because while choices are intentional, their outcomes are often not. Also, if we postulate that it’s still the right path to a “promised land” solution, then the speed at which we’re (not) getting there is one of those outcomes. ↩︎

  2. the most opinionated inhabitants of the ecosystem, which will have no qualms to go with something that’s not the newly-defined default if it doesn’t solve their problem ↩︎

  3. and all roles in between, from authors of reverse dependencies, to distributors, to administrators ↩︎

  4. which is not to downplay the outsized role they play for their user base, much less in the ecosystem ↩︎

  5. If we accept that we cannot solve 100% of all use-cases with a single tool, then some degree of forcing people to make changes is unavoidable, even just for enforcing a new default. I’d say the case would be pretty clear that this would be a good trade-off if we could cover 99% and have the remaining 1% jump through hoops. It’s less clear at 90%:10%, and even less so at 80%:20%. ↩︎

  6. of the “it would be nice to interoperate, but I need to get this to work now” kind ↩︎

5 Likes