Maturin does not see [tool.poetry] synonyms in pyproject.toml (PEP 621) #632
Comments
|
I don't think PEP 621 mandates that build backend MUST support synonyms, if it does please paste the relevant texts here. PEP 621 is designed to standardize how to store Python project metadata, what I expect is that Poetry should support the new |
It doesn't explicitly state that back-ends MUST support them, but how exactly would a tool like Poetry support [project]? What is the point of the "synonyms" the PEP mentions in that case? Poetry is not involved in building the project and generating the metadata for the wheel, only the build backend (maturin) is. I do agree it might be strange to ask the back-end to keep track of the different tools, but I'm not sure what the meaning might be otherwise. |
|
Poetry does have a tracking issue for this python-poetry/poetry#3332 |
mesejo
added a commit
to mesejo/public-letsql
that referenced
this issue
Jun 26, 2024
Letsql uses maturin as the build-backend. To handle our dependencies we use poetry. As of now, and in the future, maturin does not recognize the dependencies specified by poetry see this issue: PyO3/maturin#632 It also does not provide an alternative way to support dynamic dependencies The following issue is still open PyO3/maturin#1537 On the other side poetry will support PEP-621 project style dependencies in the version 2.0 python-poetry/poetry#3332 Therefore one simple solution is to duplicate the dependencies section, as in the package: https://github.com/tmtenbrink/rustfrc/blob/main/pyproject.toml To do so, a semi-automated approach is to generate the dependencies using poetry export poetry export -f requirements.txt --without="test,dev,docs" / --all-extras --without-hashes --output requirements.txt And then update the dependencies section in the pyproject.toml file. Additionally this commit solves a few inconsistencies regarding packages listed as optional (duckdb, ibis), but when running the code it gives errors.
mesejo
added a commit
to mesejo/public-letsql
that referenced
this issue
Jun 26, 2024
Letsql uses maturin as the build-backend. To handle our dependencies we use poetry. As of now, and in the future, maturin does not recognize the dependencies specified by poetry see this issue: PyO3/maturin#632 It also does not provide an alternative way to support dynamic dependencies The following issue is still open PyO3/maturin#1537 On the other side poetry will support PEP-621 project style dependencies in the version 2.0 python-poetry/poetry#3332 Therefore one simple solution is to duplicate the dependencies section, as in the package: https://github.com/tmtenbrink/rustfrc/blob/main/pyproject.toml To do so, a semi-automated approach is to generate the dependencies using poetry export poetry export -f requirements.txt --without="test,dev,docs" / --all-extras --without-hashes --output requirements.txt And then update the dependencies section in the pyproject.toml file. For more details on how to express poetry optional dependencies as PEP-621 optional dependencies, see the following resources: https://astarvienna.github.io/howtotoml.html#extras https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#dependencies-and-requirements https://python-poetry.org/docs/pyproject/#extras Additionally this commit solves a few inconsistencies regarding packages listed as optional (duckdb, ibis), but when running the code it raises ImportError. See the penguins_example.py for code that was raising ImportError
mesejo
added a commit
to letsql/letsql
that referenced
this issue
Jul 2, 2024
* chore: prepare for release 0.1.4 Letsql uses maturin as the build-backend. To handle our dependencies we use poetry. As of now, and in the future, maturin does not recognize the dependencies specified by poetry see this issue: PyO3/maturin#632 It also does not provide an alternative way to support dynamic dependencies The following issue is still open PyO3/maturin#1537 On the other side poetry will support PEP-621 project style dependencies in the version 2.0 python-poetry/poetry#3332 Therefore one simple solution is to duplicate the dependencies section, as in the package: https://github.com/tmtenbrink/rustfrc/blob/main/pyproject.toml To do so, a semi-automated approach is to generate the dependencies using poetry export poetry export -f requirements.txt --without="test,dev,docs" / --all-extras --without-hashes --output requirements.txt And then update the dependencies section in the pyproject.toml file. For more details on how to express poetry optional dependencies as PEP-621 optional dependencies, see the following resources: https://astarvienna.github.io/howtotoml.html#extras https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#dependencies-and-requirements https://python-poetry.org/docs/pyproject/#extras Additionally this commit solves a few inconsistencies regarding packages listed as optional (duckdb, ibis), but when running the code it raises ImportError. See the penguins_example.py for code that was raising ImportError * fix: failed logging without git
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Thanks for this great project, it greatly simplified packaging some Rust bindings!
Please provide the following information:
python -V): 3.9.5pip -V): 21.2.4pyo3,rust-cpythonorcffi): pyo3cargo buildwork? YesOn my tmtenbrink/rustfrc repository, I was originally using a dual [project] as well as [tool.poetry] section as I originally believed some metadata was only available in [project] to be read by PyPI and pip. However, after studying PEP 621 and the python poetry docs, it seems like [tool.poetry] and [project] information are synonyms. As such, it shouldn't be necessary to both have [project] and [tool.poetry] sections. However, after removing the [project] sections, the metadata is no longer present in the built wheels. As such, I believe this is a problem with maturin not adding the [tool.poetry] information to the built wheels metadata. This also means that dependencies are not transferred to the wheel metadata and they are not installed when not using pip.
In short: maturin does not see the [tool.poetry] information as synonyms. I.e. [tool.poetry.urls] is not seen as a synonym of [urls] under a [project], which I believe it should based on PEP 621.
The text was updated successfully, but these errors were encountered: