Generate badges for packages

[bennuttall]

It would be nice if we could provide dynamic badges for packages to show build status or latest version or something, giving people the chance to embed these buttons of their sites/docs/readmes, like this PyPI one:

There's a service at shields.io that allows you to provide a JSON endpoint:

We could generate the JSON in the_scribe along with JSON files. It would need updating at the same frequency.

[chris48s]

shields.io now has piwheels version badges e.g: https://img.shields.io/piwheels/v/numpy

[bennuttall]

This is great, thanks. What's the significance of the colours?

[chris48s]

Good question.

For a standard shields version badge, the colours mean:

• blue (informational) = stable release
• orange = pre-release

but in answering this question, I realise that is not exactly what is happening. I've used our standard version formatter

https://github.com/badges/shields/blob/76a64a7896893bac4a1b52e683a0a542541b3bdb/services/color-formatters.js#L16-L20

but of course, this isn't quite right for pep440 as it will format something like 2.0.0rc1 or 2.0.0b2 as "stable". I'll do a follow up PR switching it to do the colours based on the .prerelease property instead.

[chris48s]

This actually opened a small worm-can as I realised our other python ecosystem badges had the same problem, but this is now fixed upstream: badges/shields#7682

[bennuttall]

Thanks

What's supposed to happen if we have failed builds for a package? e.g. pyglm shows blue but we don't have wheels for any recent versions:

Currently it seems that it's just mirroring PyPI, not actually providing any piwheels-specific information (the use case here badges/shields#6506 wanted to be able to spot whether piwheels had fallen behind PyPI). Perhaps it should check for files under the latest version in the JSON response? Could be red for no files available.

[chris48s]

Useful example. I now see where you were going with the colours.

I think the direction I would lean in would be to show the most recent version that has >=1 files on piwheels rather than use colour to indicate build status.

So in the same way we exclude any yanked releases
https://github.com/badges/shields/blob/53cb1da830900697e61b58f6780f9e632504a397/services/piwheels/piwheels-version.service.js#L72
we would also exclude any releases where files is an empty object {}

That approach would make the badge for pyglm rather than

That would be more in line with our usual practice - a version badge shows the latest available (good/valid) version and colour indicates whether or not it is a pre-release.

I'd probably think of "piwheels build status: passing/failing" as being a seperate build status badge like

[bennuttall]

I agree that showing the latest version with (any) files would be most useful. Then all remains is what to do about a package we have zero files for.

[chris48s]

If I remove any releases with zero files as suggested above then we'd render

https://github.com/badges/shields/blob/53cb1da830900697e61b58f6780f9e632504a397/services/piwheels/piwheels-version.service.js#L74-L76
same as if all releases had been yanked, for example, which seems reasonable

[bennuttall]

Perfect!

[chris48s]

Cool. I'll get a PR done for that tomorrow

[2bndy5]

Would it be difficult to show the overall or monthly downloads count? Or should I craft something from the JSON API (using shield.io entrypoint).

[2bndy5]

For anyone that is curious about a Downloads badge, I was able to craft one for the pyrf24 package:

https://img.shields.io/badge/dynamic/json?label=piwheels%20Downloads&query=%24[%3F(%40[0]%3D%3D%22pyrf24%22)][2]&url=https%3A%2F%2Fwww.piwheels.org%2Fpackages.json

The [2] in the query field focuses on total downloads, where [1] would be monthly.

Although, I'm finding that the dynamic badge link tends to sometimes return a 502 error 🤷🏼‍♂️