Summary of discussions:
- We requested the Packaging community for feedback on the proposed survey questions
- The Python Packaging Survey was conducted in Sept-Oct. The results are summarized here.
- We asked maintainers/contributors on which forum they would like to discuss the Packaging Strategy. The most popular option was Discourse.
One of the common themes from the Packaging Survey was that the Python Packaging landscape is complex.
Survey Respondent 1 said: “Unify the multiple tools. It’s good to have new ideas and new implementations, but it has to converge after a while. If my package has a compiled part, I’m stuck with setuptools, but all other tools are pushed forward while not covering this feature.”
Survey Respondent 2 said: “There should be one– and preferably only one –obvious way to do it. Get rid of the fragmentation”
Survey Respondent 3 said: “I definitely want to Python to introduce the One True packaging tool, ideally both easy as Rust’s cargo (where building, adding dependencies, running tests, code checking and deploying are all subcommands) and extensible (support for different build regimes, extensions in foreign languages etc). Package installing is easy, package building is a wild west at the moment, and no one tool is good enough for all use cases.”
Survey respondent 4 said: “I would blow it all away and replace it with one damn thing. Too much choice leads to chaos and that chaos spills out to the user, rather than being confined to the folks choosing to revel in it. The dynamic library problem is very bad, and Python’s struggles with it are no worse, really, than those of other environments, but the choices made along the way, and the lack of consistent stern guidance from the top, have made Python’s build/deploy story a joke.”
In a nutshell, there are too many tools and users are not sure which ones to use.
Can we reduce the number of tools and bring about some form of unification? Can we do anything else to reduce the complexity?
If we do reduce the complexity, are there any obvious or not so obvious disadvantages in going down that route? If we do decide to reduce the complexity, how do we go about doing it?
- The cues listed above are only suggestions. Please add your thoughts or questions below.
- This discussion is open to any active/passive PyPA/non PyPA tool maintainer/contributor
- When posting for the first time, please indicate which tool(s) you are representing. This is for my benefit as I would like to gauge how many tools have been represented in the discussion.
- The discussion for this post will be open until Jan 20