Repository navigation
feat: support poetry v2 #839
Description
Activity
Note
in case somebody wants to champion this feature, feel free to let us know and organize yourselves in the comments section 📣
I've started using
cyclonedx-pywith Poetry 2.0.1 inrequirementsmode, and the main issue I've run into so far is not reading metadata from the PEP 621[project]section.Initially I was getting a
CRITICAL | CDX > 'name'fatal error, but adding a duplicate of the name field in the[tool.poetry]section fixed that (though now Poetry emits a warning about duplicate fields).(This may be irrelevant if I switch over to using
uvfor packaging, though.)We recently upgraded to Poetry v2 and changed to using the
[project]table in the pyproject.toml, but Cyclone DX doesn't seem to support the dependencies defined in that table and they are not included in the SBOM.xml output.I can see in poetry.py there's only mention of the
[tool.poetry]section, so it appears it will only be considering dependencies defined there and won't consider one's in[project].If that's right, then I would like to see support for Poetry 2 and the PEP621
[project]standards.
Please let me know if I've misunderstood this though!(I'd consider attempting to contribute if I had a bit of help as well)
i did not look into all details of poetry2's docs.
could you point me to the docs, where they allowprojectinstead oftool.poetry?BTW: PEP621 is already implemented: https://github.com/CycloneDX/cyclonedx-python/blob/main/cyclonedx_py/_internal/utils/pep621.py
It is just not applied, since poetry went withtool.poetry, in the past.https://python-poetry.org/docs/managing-dependencies/
Poetry supports specifying main dependencies in the project.dependencies section of your pyproject.toml according to PEP 621. For legacy reasons and to define additional information that are only used by Poetry the tool.poetry.dependencies sections can be used.
@jkowalleck it's stated in the release notes for poetry 2.0.0
Since 2.0.0 poetry prints a warning if
name,description, etc are specified in thetool.poetrysection ofpyproject.tomlReacted by Jan Kowalleck and Armin GertenWe are also heavily awaiting the support for poetry 2 for cyclonedx-py. However, I have been thinking about the following work-around:
poetry export | cyclonedx-py requirements -
Doesn't this yield the same result as
cyclonedx-py poetry(with poetry 2 support)?poetry export | cyclonedx-py requirements -
Doesn't this yield the same result as
cyclonedx-py poetry(with poetry 2 support)?not at all.
have you tried it?We are also heavily awaiting the support for poetry 2 for cyclonedx-py
Everyone is awaiting, nobody is contributing - yet.
Feel free to champion this feature, I will be there to assist you.Doesn't this yield the same result as
cyclonedx-py poetry(with poetry 2 support)?not at all.
Hmm, what's the difference? 🤔
We are also heavily awaiting the support for poetry 2 for cyclonedx-py
Everyone is awaiting, nobody is contributing - yet. Feel free to champion this feature, I will be there to assist you.
Yeah, I get that. I didn't intend to put pressure on anyone with that. I was just showing my interest in this issue 😉
In the meantime, I suggest looking into
cyclonedx-py environment- https://cyclonedx-bom-tool.readthedocs.io/en/latest/usage.html#for-python-virtual-environment
It is probably the most true and complete BOM you could get.Reacted by Armin Gerten, Igor Kiulian and Tewfik GharianiThanks for the hint to
cyclonedx-py environment!So
cyclonedx-py environment "$(poetry env info --executable)" --pyproject ./pyproject.tomlseems to be even superior to
cyclonedx-py poetryI just noticed that specifying the
--pyprojectparameter would also yield an error (CRITICAL | CDX > 'name') when using the PEP621 style in your pyproject.toml.Reacted by Igor KiulianI just noticed that specifying the --pyproject parameter would also yield an error
Can we simply update priority, take first
[project]if present instead of[tool.poetry]here
cyclonedx-python/cyclonedx_py/_internal/utils/pyproject.py
Lines 33 to 40 in 12cc59b
Can we simply update priority, take first
[project]if present instead of[tool.poetry]hereunfortunately not. please read this very ticket's (updated) description:
any new
pytproject.tomldeclarationssupport for PEP621 - metadata and dependencies
Goal: not either/or, but simultaneously the "old"tool.poetryand the "new"projectAdd support for the
projectsection in thepyproject.tomlfile according to PEP 621started looking into this.
will provide test setups (lockfiles) for poetry v2 for the existing cases, and see how this turns out.
from there on, i might adjust the ticket's description to reflect needed tasks.Done:
feature development may start, now
Just for clarification, is using the union operator on both possible dictionaries enough?
The goal would be fulfilled, we'd support both versions simultaneously. Or am I missing something?E,g,:
in
cyclonedx_py/_internal/poetry.pypo_cfg = project.get('project', {}) | project['tool']['poetry']
and
cyclonedx_py/_internal/utils/pyproject.py:if poetry := tool.get('poetry') | data.get('project', {}): return poetry2component(poetry, ctype=ctype)
Just for clarification, is using the union operator on both possible dictionaries enough?
not quite.
Poetry v2 added a lot of capabilities.
You'd better read their docs - find out what they support, where they might pull data from, and such.Reacted by Leo Reinmann and Panpakorn Siripanich
poetryv2 just got released: https://github.com/python-poetry/poetry/releases/tag/2.0.0Let's add support for it and it's new features, if any
pytproject.tomldeclarationsGoal: not either/or, but simultaneously the "old"
tool.poetryand the "new"project2.1. this means we can keep current test structures and add a new folder for each lockfile thing where needed.[⤴ this list will be updated continuously based on comments below, until the initial feature was provided eventually]