-
-
Notifications
You must be signed in to change notification settings - Fork 250
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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 |
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.
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
* 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
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-cpython
orcffi
): pyo3cargo build
work? 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: