pyosmeta missing joss doi and sometimes parsing DOI values differently; we should add some checks for consistency

[lwasser]

In some issues, we have a line that is JOSS DOI, and in others, it is JOSS: . Because of this sometimes pyosmeta misses finding the JOSS DOI for a package. it would be good to make pyometra flexible enough to accept either as viable for the JOSS attribute in our model. This relates to this issue because, in many cases, our website isn't rendering doi information correctly.

A few other places where it's failing oddly

xclim it's returning true for some reason? I am not sure why as it looks similar to other packages in the review issue

I think the bigger picture here is that we need pyosmeta to do a few things when parsing both the archive field and the joss doi

1. sometimes for archive, a user provides a link to a github release or tag. If that is the case we should return a new field called release_tag: that contains that url
2. for joss - we need to ensure pyosmeta can handle both joss and joss doi when it parses our issues
3. for zenodo - we need to make sure that
   • the user provides a badge
   • if they don't make one but provide a zenodo link, we can parse that url into a badge
   • if they provide the latest badge let's put it in another yaml element called latest_doi:
   • this will make the website parsing side of things easier.

We should also validate that there is a valid url provided within the badge.

[banesullivan]

@lwasser, I think I solved most of this in #243

• ✅ JOSS vs JOSS DOI as the label is now handled
• ✅ For xclim, the JOSS DOI is now correct in https://github.com/pyOpenSci/pyopensci.github.io/blob/abc078dc7b815b46752d0b6d3ec561cc2bb99ecc/_data/packages.yml#L1306
• ✅ We are parsing the archive link out of Zenodo badges
• ✅ We are validating the the DOI link is valid

a user provides a link to a github release or tag. If that is the case we should return a new field called release_tag: that contains that url

This is the only thing I did not account for

[lwasser]

@banesullivan great. Right now, how are GitHub releases handled? We dont necessarily need a new field. my thought was we might want to parse it differently on the website if it's github vs a doi. i can be convinced otherwise! this isn't critical, especially if we have working urls now for the archive.

[lwasser]

Let's close this issue. we can revisit releases and format IF that becomes an issue in the future.