proycon/codemetapy

Incorrect parsing of versions from dependencies if e.g. extras are stated to be installed

apirogov opened this issue · 2 comments

pyproject.toml:

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

[tool.poetry.dependencies]
python = "^3.8"
pyproject-parser = "^0.9.0"
typer = {extras = ["all"], version = "^0.7.0"}
tomli = "^2.0.1"
codemetapy = "^2.5.0"

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

Log:

No input files specified, but found python project (pyproject.toml) in current dir, using that...
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
WARNING: No translation for distutils or pyproject.toml key readme
WARNING: No translation for distutils or pyproject.toml key packages
Found dependency python ^3.8
Found dependency pyproject-parser ^0.9.0
Found dependency typer {'extras': ['all'
Found dependency 'version': '^0.7.0'}
Found dependency tomli ^2.0.1
Found dependency codemetapy ^2.5.0
[CODEMETA COMPOSITION (dummy-project)] processed 48 new triples, total is now 49
[CODEMETA VALIDATION (dummy-project)] codeRepository not set
[CODEMETA VALIDATION (dummy-project)] license not set
[CODEMETA VALIDATION (dummy-project)] done
{
    "@context": [
        "https://doi.org/10.5063/schema/codemeta-2.0",
        "https://w3id.org/software-iodata",
        "https://raw.githubusercontent.com/jantman/repostatus.org/master/badges/latest/ontology.jsonld",
        "https://schema.org",
        "https://w3id.org/software-types"
    ],
    "@type": "SoftwareSourceCode",
    "author": [
        {
            "@type": "Person",
            "email": "j.doe@example.com",
            "familyName": "Doe",
            "givenName": "John"
        }
    ],
    "description": "",
    "identifier": "dummy-project",
    "name": "dummy-project",
    "runtimePlatform": "Python 3",
    "softwareRequirements": [
        {
            "@type": "SoftwareApplication",
            "identifier": "'version':",
            "name": "'version':",
            "runtimePlatform": "Python 3",
            "version": "'^0.7.0'}"
        },
        {
            "@type": "SoftwareApplication",
            "identifier": "codemetapy",
            "name": "codemetapy",
            "runtimePlatform": "Python 3",
            "version": "^2.5.0"
        },
        {
            "@type": "SoftwareApplication",
            "identifier": "pyproject-parser",
            "name": "pyproject-parser",
            "runtimePlatform": "Python 3",
            "version": "^0.9.0"
        },
        {
            "@type": "SoftwareApplication",
            "identifier": "python",
            "name": "python",
            "runtimePlatform": "Python 3",
            "version": "^3.8"
        },
        {
            "@type": "SoftwareApplication",
            "identifier": "tomli",
            "name": "tomli",
            "runtimePlatform": "Python 3",
            "version": "^2.0.1"
        },
        {
            "@type": "SoftwareApplication",
            "identifier": "typer",
            "name": "typer",
            "runtimePlatform": "Python 3",
            "version": "{'extras': ['all'"
        }
    ],
    "version": "0.1.0"
}

So apparently the parsing does not work if the deps are not simply a string, but have e.g. extras stated.

The solution would be to check whether the versions are strings, if not to check if they are dicts and use the version key on them.

Good catch, the above commit should fix this.

Fixed and released now