Package request: poetry-core

[kwshi]

Purpose: Support Python packages built using Poetry (via PEP 517).

The Python community is moving increasingly towards Poetry as a de-facto project management/build tool (I have no stats to back this claim up, only speculation based on an increasing number of blog posts I have seen about Poetry, as well as my own pleasant experiences with it). Together with PEP 517, this trend means that

• several existing Python packages are migrating from setup.py-based builds to PEP517+Poetry builds (e.g., see Packaging python poetry #29799),
• new Python projects are likely to be created from scratch using Poetry (and therefore built using Poetry as well).

Not supporting Poetry would mean that it will be difficult to upgrade certain Python projects that have migrated to Poetry (e.g. #29799) as well as new projects created with Poetry. One popular example of such a library is tomlkit, which has 300+ stars on GitHub.

As far as I can tell, the existing Void packages repo does not yet support Poetry-based builds. The infrastructure is already in place: PEP517 build configurations are supported via build_style="python3-pep517"; the missing part is the Poetry builder itself, namely poetry-core, which is loaded by the PEP517 build runner when a project specifies Poetry as the build backend (example) and therefore needs to be present as a build-time dependency.

That means the only thing that needs to be done to support (a vast & popular collection of, and likely even more so in the coming years) Poetry-based Python packages is to add the poetry-core Python package.

Note that poetry-core is not the same as the Poetry CLI, which is an interactive/user-friendly frontend to managing Poetry-based projects. Only poetry-core, which is a lightweight, zero-dependency library, not the CLI, is needed for building via PEP517.

[eli-schwartz]

The python3-pep517 build style just runs pip, see commit 2dff49c

PyPI release tarballs created with poetry build -f sdist should have a setup.py generated for compat purposes, which lets you use the more common setup.py build style; getting distfiles via github archives will not get you an sdist and therefore you won't have that setup.py either. You'll just have development sources.

On the flip side, sometimes upstreams don't include their testsuite in PyPI sdists (they should!) which may be a compelling argument to use github archives.

[kwshi]

Added in 0f451e9.