3 ms·
Anything that takes away from users fully migrating to pyproject really needs to die.
by skeledrew 2y ago
Anything that takes away from users fully migrating to pyproject really needs to die.
- mikepurvis 2y agoBut 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.)
- skeledrew 2y agoThere 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/pyproject-toml/ https://packaging.python.org/en/latest/specifications/pyproj...
- joeyagreco 2y agoand why is that?
- skeledrew 2y agoBecause 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/ https://peps.python.org/pep-0621/ [1] https://peps.python.org/pep-0020/ https://peps.python.org/pep-0020/
- hiccuphippo 2y agoThis project looks like a first step to migrate something to pyproject.
- skeledrew 2y agoNo need for the intermediate step. It's a straight shot to generating a pyproject.toml file.