pyroma
pyroma copied to clipboard
Support poetry
Any plans to support non-setuptools-based projects. Poetry-projects use pyproject.toml instead of setup.py.
Hey, thanks for the ping. IMO, the best way to implement support would be to read PEP 621-standardized metadata from the pyproject.toml, which shouldn't require too many code changes and support any PEP 518 build backend that supported PEP 621, rather having to read and translate each tool's bespoke format (which may look very different from the standard metadata pyroma is currently set up to evaluate). However, while some tools (e.g. flit) have, as far as I'm aware per python-poetry/poetry#3332 , Poetry has been rather slow to do, which has to do with the maintainer having some personal gripes with PEP 631, based on the existing PEP 508 dependency spec being accepted for PEP 621 instead of something closer to what Poetry natively uses. Until that happens, I'm not sure how much value there would be in trying to manually graft Poetry's own bespoke format onto the standardized metadata fields this tool evaluates.
Reopened this as that PR only implemented PEP517 support, and not PEP621, so I don't know if it enough for poetry support.
But beta 4.0b1 is out.
It would be good for @WouterVH or someone else using Poetry to test to confirm there aren't any other issues, but yes, PEP 517 support is what is needed here; PEP 621 is not necessary*
, as the approach implemented in #73 will work for all buildable packages, that use either legacy setuptools or any (PEP 517) build backend, regardless of project source configuration format, In fact, Poetry itself (unlike all the other major build backends) still doesn't even support PEP 621 yet.
*
(its possible and somewhat more efficient to read the metadata directly from a PEP 621 [project]
table in pyproject.toml
, rather than having to call prepare()
first, but if any needed fields are specified as dynamic
, the current approach is still required anyway, as well as for projects that don't define their packaging metadata in [project]
(currently, the great majority), and that wouldn't work for Poetry at all since it still doesn't yet support PEP 621.
Seems like there still is one issue with PEP 517 support for arbitrary backends that I discovered thanks to the new test in #78 , but thankfully its not only an easy fix but actually simplifies Pyroma's code (taking care of things that were previously being handled manually).
PR #92 finally fixes this, as well as several other issues