[markbujehein]

lib_doi in .copier-answers.yml was set to the default DOI from the template.
This sets it and the docs link to core's concept DOI, 10.5281/zenodo.19918609,
as per the Zenodo ADR easyscience/.github#55.

This address #335 wrt to the ADR, which states the DOI should be the Concept DOI, but might not be the full solution that is desired. See my follow-up comment below.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.24%. Comparing base (511a8e4) to head (1bf36cb).

Additional details and impacted files

@@           Coverage Diff            @@
##           develop     #339   +/-   ##
========================================
  Coverage    83.24%   83.24%           
========================================
  Files           63       63           
  Lines         5324     5324           
========================================
  Hits          4432     4432           
  Misses         892      892           

Flag	Coverage Δ
unittests	83.24% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

[markbujehein]

Follow-up

Versioned docs (or any versions files) could perhaps find a use for the specific version DOI¹. Zenodo only creates it after processing the GitHub release, so it can't be templated. However, the public Zenodo REST API² can look it up by concept ID and tag; I had @claude make this MWE:

import json
import sys
import urllib.parse
import urllib.request

CONCEPT_RECID = '19918609'  # easyscience/core


def version_dois(tag, concept_recid=CONCEPT_RECID):
    query = urllib.parse.urlencode({
        'q': f'conceptrecid:{concept_recid} AND metadata.version:"{tag}"',
        'all_versions': 'true',
    })
    with urllib.request.urlopen(f'https://zenodo.org/api/records?{query}') as response:
        hits = json.load(response)['hits']['hits']
    return [hit['doi'] for hit in hits]


if __name__ == '__main__':
    for tag in sys.argv[1:]:
        print(tag, version_dois(tag))

which returns,

> python ~/zenodo_version_doi.py v2.5.1 v2.5.0 v2.3.1
v2.5.1 ['10.5281/zenodo.21719766']
v2.5.0 ['10.5281/zenodo.21718592']
v2.3.1 ['10.5281/zenodo.20024797', '10.5281/zenodo.20026291']

If this serves a use, some caveats would also have to be taken into consideration, and an automatic post-release job would:

• have to retry until the record exists,
• have to match the tag exactly, and
• also have to handle duplicates, whether intentional or not: e.g., v2.3.1 is
  archived twice (10.5281/zenodo.20024797, 10.5281/zenodo.20026291).

Footnotes

1. https://zenodo.org/help/versioning/ ↩

2. https://developers.zenodo.org/ ↩

[damskii9992]

LGTM