Closed apirogov closed 11 months ago
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.
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.
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
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...
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!
Result:
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 usingpyproject.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.