Python Packaging Strategy Discussion - Part 1

There’s certainly unfinished business in pip. It’s a software tool, it’s always going to have things to fix or improve.

Can you elaborate on what aspect of environment management is challenging to fit into pip?

In my opinion, if pip did the following:

  1. added support for PEP-582 (or venv-by-default)
  2. settled on a lockfile format
  3. supported a publish flow

Those items (along with existing functionality and ongoing improvements), would address ~90% of the requirements that I’ve encountered in projects as a python developer over the last 10 years.

Yes, it doesn’t solve everything. There’s still lots of challenges around native extensions, static metadata etc, but I would be very surprised if the reception from the community wasn’t warm with this simplification of the ecosystem. It simplifies docs and concepts that users need to understand, it simplifies tools people need to install, it centralises effort of many of the leading experts in python packaging in the same project.

Yes, it won’t be easy. Yes, it’s a 180 degree pivot from the previous direction. However, I personally think it could be transformational if there was a consolidation of efforts behind a single tool after so many years of trying to increase the diversity of tools. To be clear, I think this ebb and flow is natural. But it’s clear from the survey and from most general python developers I speak to, that it’s possibly over corrected towards diversity and now there are too many choices with a dizzying number of PEP numbers that most users honestly don’t care about or understand.

3 Likes