Here is the link: https://zenodo.org/record/8042522
Documentation and repo URL have been added to the Zenodo description. I also added 'copyrightHolder'
and 'releaseNotes'
. I released 1.0.1 with clean (single) tarball ;)
Should I add ESCAPE/824064 to funder/funding
to Codemeta? The Zenodo entry already has those.
Sorry, I did not put that on my daily todo list and forgot about it ;)
Yes, I'll do today!
All fine, ready for merging! Thanks for this nice contribution :)
=== Record #7637182 ===
Title: cds-astro/mocpy: Release v0.12.0
DOI: 10.5281/zenodo.7637182
URL: https://zenodo.org/record/7637182
Python library to easily create and manipulate MOCs (Multi-Order Coverage maps)
Related onboarding issue: XXX (to be entered by onboarding manager)
There are 5 missing recommended keys:['memoryRequirements', 'processorRequirements', 'storageRequirements', 'copyrightHolder', 'identifier']
Yes, the validation was already done, it was just not listed in the MANIFEST
so python setup.py sdist
did not pick up the file ;) Now it's included and I created a new version (and entry in Zenodo).
I just realised that the codemeta was not packaged in the zenodo tar ball ;) I'll fix that asap.
=== Record #5888553 ===
Title: gLike
DOI: 10.5281/zenodo.5888553
URL: https://zenodo.org/record/5888553
gLike is a general-purpose ROOT-based code framework for the numerical maximization of joint likelihood functions.
The joint likelihood function has one free parameter (named g) and as many nuisance parameters as wanted, which will be profiled in the maximization process.
Related onboarding issue: https://project.escape2020.de/issues/37
There are 5 warnings:
memoryRequirements
not provided in the codemeta schema but is recommendedprocessorRequirements
not provided in the codemeta schema but is recommendedreleaseNotes
not provided in the codemeta schema but is recommendedstorageRequirements
not provided in the codemeta schema but is recommendedcopyrightHolder
not provided in the codemeta schema but is recommendedThere are 3 errors:.
Thanks, all mandatory fields are fine now!
These three errors are currently blocking the progress:
Sorry, I missed this issue. I'd use a requirements with semantic versioning in mind, so that we would specify requests>=2.25 and requests<3 for example (this would be requests ~= 2.25
in the pip requirements syntax). This will make sure that at least from the SemVer point of view we are safe (the API will not change, only expand).
Yeah!
Regarding reproducibility, I think it would be good if the dependencies were constrained, regarding their versions:
Collecting requests
Downloading requests-2.26.0-py2.py3-none-any.whl (62 kB)
Collecting bs4
Downloading bs4-0.0.1.tar.gz (1.1 kB)
Collecting beautifulsoup4
Downloading beautifulsoup4-4.10.0-py3-none-any.whl (97 kB)
Using bs4
is especially a bit dangerous since it's just a dummy package and points to an "undefined" beautiful soup requests
though may do a breaking change at any point (even if unlikely).
This all is less for safety and more for being a good example ;)
I agree with all points. I also think that maintaining a registry with base images is a good idea, to provide a safe starting point.
Yes, I wanted to mention the parser but forgot about it
That's a good start, we can make it fancy later