# Python Packaging Strategy Discussion - Part 1 **URL:** \ **Category:** Packaging\ **Created:** [January 4, 2023, 11:13am UTC](https://discuss.python.org/t/python-packaging-strategy-discussion-part-1/22420 "2023-01-04T11:13:19Z")\ **Posts on this page:** 1\ **Showing post:** 133
**Author:** ![abravalheri](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/abravalheri/32/4990_2.png) [@abravalheri](https://discuss.python.org/u/abravalheri)\ **Post date:** [January 12, 2023, 9:53pm UTC](https://discuss.python.org/t/python-packaging-strategy-discussion-part-1/22420/133 "2023-01-12T21:53:01Z")
_(I help to maintain setuptools, but I don’t speak for the project, these are my personal opinions)_ > [@smm](#): > > 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 following is a comment on how I think we should do an unification_ If we ever unify the tools for Python packaging, I think it is important for this hypothetical tool to be able handle _legacy_: - It is not fair with users to say: “now we have this single tool that everyone is supposed to use” but if they need an older package, expect them to ignore all the most recent documentation that can be found on the topic and go figure out how to maintain something different. - It is not fair with any tool developer to discourage the use of a tool but at the same time place the burden of maintenance of the ecosystem in their shoulders. This is not easy and requires a lot of work. Of course there is also another way: declare everything that is not compatible with this hypothetical tool unsupported, as mentioned by Paul: > [@pf\_moore](#): > > Historical complexity _can_ be removed, but do we have the stomach (or the resources) for deliberately breaking how a lot of users work? As I said, I doubt any of the survey respondents were asking for a unified tool that didn’t support their workflow… * * * * * * * * * _The following is not an argument against or in favour of the proposal, just me expressing feelings and thoughts that have been puzzling me. Hindsight bias, I know, but it is not easy to ignore…_ It is important to recognize that this problem of “too many tools” (if indeed this is really a problem), is partially a problem of our own making. Years ago there were some “de-facto” standards in the ecosystem, and the packaging community invested a lot of effort to create standards (with a more or less declared goal of removing the monopoly of such tools). My opinion is that it was a noble goal, it incentivised the openness, and created opportunities to handle niche requirements or to experiment and try new things. Going back to “there is only one blessed tool” feels like a throwback… If this was the goal since the beginning, the community could have saved time/money/energy if everyone worked together to fix/improve/rebuild existing tools instead of splitting the efforts. Is it respectful of the work people have put in? (I don’t speak only of setuptools, but in general). The maintainers have put love and hours of work trying to make the ecosystem better by creating and complying with interoperability PEPs… If they had knew since the beginning that eventually PSF would endorse only one tool and “would not recommend X”, would they invest the same amount of love/effort? Was it worthy to comply with interoperability PEPs? Would it have been better instead if we all had worked together towards making a new tool and to move all the packages to this tool? Moreover, is it respectful of the work the users had to put in to adapt? This process of standardisation was the source of a lot of “growing pains” that was imposed to the community because at that point in time it was deemed necessary that no single tool had preferential treatment in the Python packaging ecosystem. But now we are talking about giving a single tool preferential treatment… --- _[View the full topic](https://discuss.python.org/t/python-packaging-strategy-discussion-part-1/22420)._