shields icon indicating copy to clipboard operation
shields copied to clipboard

PyPI prerelease version badge

Open paulmelnikow opened this issue 4 years ago • 11 comments

:clipboard: Description

I just published a prerelease of tinyobjloader:

https://pypi.org/project/tinyobjloader/#history

As far as I can tell, there isn't a badge for displaying the latest prerelease version.

It looks like if there are only prereleases, they do show correctly, e.g.

https://img.shields.io/pypi/v/black

:link: Data

It looks like the data source we use now includes both of the releases for this project, 0.1 and 2.0.0rc5.

https://pypi.org/pypi/tinyobjloader/json

:microphone: Motivation

It's common for projects to run prereleases for a long time, and it's useful to show users the latest published prerelease.

paulmelnikow avatar Feb 26 '20 22:02 paulmelnikow

As far as I can tell, there isn't a badge for displaying the latest prerelease version

I think the reason we haven't done this is: With PyPI, we defer to the registry to tell us which is the "latest" version. Beyond that, PyPI's API doesn't explicitly mark releases as pre-release or stable. This means we would have to make our own decision about which releases are pre-release and which are stable.

Most (all?) packages on PyPI follow PEP440 rather than semver, so we'd need a javascript implementation of PEP440 for that case (which is a thing that does exist https://github.com/renovatebot/pep440 ). I'm not 100% sure if PyPI enforces PEP440 or not though. If it does, "all package versions are PEP440-compliant" is a reasonable assumption and we could just roll with that. If it doesn't, we're then on shaky ground with that assumption as there will inevitably be some packages in the registry with non-compliant versions.

chris48s avatar Feb 26 '20 23:02 chris48s

I don’t know if PyPI enforces PEP440 either. It does seem to normalize version numbers (e.g. if you upload a package with beta6 it will allow fetching it with beta6 but at least lists it as b6: https://pypi.org/project/polliwog/#history

Beyond that, PyPI's API doesn't explicitly mark releases as pre-release or stable.

Prereleases are defined in PEP440 and fortunately would be relatively easy to detect using regex.

One option that would solve my use case would be to have an option that returns the latest release by date. There are upload dates in the JSON, although they might have to be aggregated across the various sdists and wheels.

I know you worked a lot on the GitHub release badges so I bet you have this problem a lot more in your head than I do. 🤔

paulmelnikow avatar Feb 27 '20 04:02 paulmelnikow

Just thinking about it in slightly more detail..

PyPI does flag releases as pre-release in the front-end (its just not exposed via the API):

Screenshot at 2020-02-27 17-20-52

Looking at the warehouse source, the code for doing that is:

https://github.com/pypa/warehouse/blob/1fbb4ac752e68b5840b9e09b68e44a165569bfa6/warehouse/migrations/versions/e7b09b5c089d_add_pep440_is_prerelease.py#L29-L34

so we could replicate the same method for identifying whether a version is stable or pre-release but I think we'd still want to use https://github.com/renovatebot/pep440 for comparing/sorting versions to determine the latest in the pre-release case.

chris48s avatar Feb 27 '20 17:02 chris48s

It would be great if we can get a Pre Release PyPI version badge just like NPM @ next. +1

huan avatar Mar 09 '20 17:03 huan

latest in the pre-release case.

latest by release date or greatest version number?

graingert avatar Oct 01 '20 08:10 graingert

Here's some discussion around making an API https://github.com/pypa/warehouse/issues/4663

graingert avatar Oct 01 '20 08:10 graingert

Thanks :+1: I've subscribed to https://github.com/pypa/warehouse/pull/8615 - we'll see how it plays out

chris48s avatar Oct 01 '20 18:10 chris48s

Looks like that won't happen soon.

One option that would solve my use case would be to have an option that returns the latest release by date.

This is probably the way to go, and would work well for the project I'm thinking of right now, https://github.com/hylang/hy. The shield is stuck at 0.20.0 although we've released several alphas since then.

Kodiologist avatar Jan 09 '22 19:01 Kodiologist

Another option would be to add a parameter to the badge that allows to specify a specific version (or add another endpoint for that). E.g. /pypi/pyversions/:packageName?version=v0.0a1.

Bibo-Joshi avatar Aug 23 '22 08:08 Bibo-Joshi

The NuGet Version badge supports pre-releases.

image

It would be really nice if there was a similar option for PyPI.

EwoutH avatar Apr 24 '24 07:04 EwoutH

+1 to the pre option. If you have both Python and NuGet packages, and want to show the latest, your badges look a little weird

natke avatar Apr 24 '24 21:04 natke