codemetapy fails on pyproject.toml if some other tool section comes before tool.poetry

[apirogov]

[tool.something]
this = "does not work"

[tool.poetry]
name = "dummy-project"
version = "0.1.0"
description = ""
authors = ["John Doe <j.doe@example.com>"]
readme = "README.md"
packages = [{include = "dummy_project"}]

include = [
  "CHANGELOG.md",
  { path = "tests", format = "sdist" },
]

[tool.poetry.dependencies]
python = "^3.8"
pyproject-parser = "^0.9.0"
tomli = "^2.0.1"

[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"

Result:

Passed 1 files/sources but specified 0 input types! Automatically guessing types...
Detected input types: [('pyproject.toml', 'python')]
Note: You did not specify a --baseuri so we will not provide identifiers (IRIs) for your SoftwareSourceCode resources (and others)
Initial URI automatically generated, may be overriden later: file:///pyproject-toml
Processing source #1 of 1
Obtaining python package metadata for: pyproject.toml
Loading metadata from pyproject.toml via pyproject-parser
Failed to find complete enough metadata in pyproject.toml
Fallback: Loading metadata from pyproject.toml via PEP517
...
(fails)

Expected behavior: codemetapy finds tool.poetry section regardless of its position. TOML like JSON has no intrinsic order for objects, so it should make no difference.

Solution:

Fix these lines: https://github.com/proycon/codemetapy/blob/master/codemeta/parsers/python.py#L155-L156

The object tool is a dict, why not just look up directly using pyproject.tool["poetry"] ?

I don't think it makes sense to assume that other tools would provide equivalent metadata so keeping it that "open" does not work (e.g. we are building a new tool to specify exactly that kind of metadata, and this is how I stumbled on that bug). Also assuming that the first one will be the right one is incorrect anyway.

[proycon]

Thanks, that's a good point indeed. The implementation is clearly not optimal here. I was trying to keep it too open because I do not really know what other tools are 'out there' besides poetry. I suppose I can't make any assumptions about the metadata fields for other tools anyway.

I'll adapt the code to look for poetry explicitly.

[proycon]

i found the accepted answer here also enlightening to illustrate the differences between [project] and [tool.poetry]: https://stackoverflow.com/questions/75408641/whats-difference-between-tool-poetry-and-project-in-pyproject-toml . Mentioning it here for future reference when I forget again.

[apirogov]

I tested the version from the main branch and it seems to work now. Could you create a new patch release 2.5.1 so I can properly update the deps? Thanks!

@proycon

[apirogov]

We need that to release our own tool to PyPI, which depends on codemetapy and needs the fix that is currently only on the main branch and not published yet...

[proycon]

I tested the version from the main branch and it seems to work now. Could you create a new patch release 2.5.1 so I can properly update the deps? Thanks!

Sorry it took so long, released now!