Python Packaging Strategy Discussion - Part 1

Right now the scenario that I have in mind from a UX point of view would be something like this:

1. Some kind of “bootstrap” tool:

  • easy to distribute, install, update, and use
    • possibly a single file binary (not necessarily written 100% in Python *)
    • release schedule independent from Python versions
  • feature scope and use cases:
    • (make sure to cater to the simplest cases only, no feature creep)
    • install and manage Python interpreters à la pyenv
      • possibly others than just regular CPython
    • install and manage (lightweight) Python applications à la pipx
      • consumer of lock files
    • run Python scripts and commands à la py launcher
      • this could be the place to include support for __pypackages__ without changes to the Python interpreter itself

* Most features would require a Python interpreter to be installed anyway, so once this is done the work can be delegated to some Python code executed by the Python interpreter

2. A “developer” tool

From my point of view this could be hatch, pdm, or poetry. I think I would prefer this tool not to be pip (but if it is, it is fine by me). Maybe pip should stay focused on what it already does best, installing things, and maybe even unlearn things like pip wheel.

I think PyPA should pick one (hatch, pdm, pip, poetry, or whatever), not overthink it too much, and then slowly build it up into the thing that covers “the opinionated PyPA workflow(s)™”.

PyPA should choose, document, and recommend things like the project directory structure (src-layout, .venv at the root, tests?), handling of janitorial tasks, and so on. This step is important because then when a project does not adhere to this workflow, PyPA can say “sorry not supported by us” and move on (focus on the hard things: lock files, hard to compile dependencies, metadata override).

On the other hand PyPA should still work on writing the standards and libraries that are less opinionated, in order to nurture a healthy competitive ecosystem for things that PyPA does not want to (can not) support.


I guess a good rule to decide if a feature should belong in the bootstrap tool or in the developer tool would be whether or not the task requires writing Python code. For example if I want to use httpie, I should be able to do it without using the developer tool. If I want to create a library I should not be able to do it with the bootstrap tool.

I think the bootstrap tool was already described earlier in this thread (was it under the pyup name?). I would like to see such a tool, I would most likely use it every day.


Yes to finding a technical project manager (to write down specs and requirements), then get funding, and finally hire developers.

3 Likes