Python Packaging Strategy Discussion - Part 1

(I’m not necessarily representing any project, but I am a maintainer of pypa/build, meson-python, and sysconfig)

I think so, but it’d require a great effort, which means it probably won’t happen without any funding.

It may be obvious to some, but I just wanted to highlight this: just unifying tools won’t do any good, we need to do a full UX analysis and then design something that fills the needs of users more naturally.

IMO, a unified frontend for all the different tasks we have is something worth pursuing, but it needs to be lead by someone/team with a strong UI/UX background.
It also shouldn’t replace existing tooling, but rather just re-export the functionality in a more coherent manner. This lets development be driven by area experts, in projects meant to target each of the required tasks specifically, leaving this unified tool as really just a UI project mostly.

pip already tries to do this, but it is burdened with historic decisions, and lack of maintainer time AFAICT. I am not sure if a clean slate would be worth, but it’s probably something it would make sense to consider – if we can find a big enough workforce to work on it, that is, which is the main problem.

TLDR: Lack of maintainer time is the main issue in the packaging ecosystem right now, but if we can fix that, my proposal would be to split each technical challenge into their own standalone project, and then have a unified tool re-exporting the functionality, with a team that is solely focusing on UI/UX.

IMO, there are two main factors that drive complexity in the Python packaging ecosystem, the first being historic decisions, which cannot be fixed without breaking things for lots of users, and the second being, because lots of things are inherently complex, and we are already doing our best to reduce complexity, so I don’t think there’s much we can do there other than providing more resources to projects to help tackle them.

6 Likes