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 is the topic of this discussion).

I don’t think this is a fair assessment. The PyPA focus is on supporting the “standard” builds of Python (, Linux distro builds, Windows Store, self-built interpreters, Homebrew, …) Solutions that require the user to switch to a different Python build don’t fit that remit. I don’t think that “declare all of those Python builds as out of scope” has any more chance of being acceptable to the SC than “declare a big chunk of the user base” does.

Maybe that does mean that we need two independent (but hopefully co-operating!) tool stacks. That’s something that could come out of this discussion. But even then, why does the UI have to be completely different? Could we not have a unified UI with different “backends” somehow? At the moment, we’re focusing on the technical challenges of the backends, but this discussion is supposed to be about the user experience - so maybe a standard command structure that both conda and “the PyPA tool” follow is an acceptable compromise here.

Overall, your comments sound pretty pessimistic. I’d much rather we approached the discussion with a more positive attitude - we’ve been given a pretty clear indication from the user survey that a “standard frontend” is something that our users want, let’s see how we can approach that goal, even if the technical challenges behind the scenes make it difficult to do everything we believe the users want. is a great example of this[1]. It sets out the technical challenges without presuming a particular solution. Maybe we could do something similar for the front end - document what users want to do, as opposed to what tools currently let them do, and clarify the challenges involved in delivering that without focusing on the limitations or constraints of particular tools.

  1. I believe you were involved in producing this document, so many thanks for your efforts in that. ↩︎