Hacker News Reader

But pyproject itself isn't even taking a stance on the underlying question of dependency management, which can still be flit, poetry, uv, pipx, pipenv, and who knows what else.

(I'm a poetry user myself, but I can see the writing on the wall that poetry is probably not going to be the winner of who ultimately ends up in the PEP.)

There isn't a stance on the build backend itself, beyond supporting the basics[0]. The spec itself however exists as the accepted successor to requirements.txt, and I think is actually implemented by all but the last tool in your list.

[0] https://packaging.python.org/en/latest/specifications/pyproj...

This project looks like a first step to migrate something to pyproject.

No need for the intermediate step. It's a straight shot to generating a pyproject.toml file.

and why is that?

Because it's wasted resources for anything that isn't in line with said spec[0]. There should ideally be only one explicit way[1] to do a thing.

[0] https://peps.python.org/pep-0621/ [1] https://peps.python.org/pep-0020/