Python (PyPi) version numbers padded with '.0' about deps.dev HOT 2 CLOSED

Hello, thanks for getting in touch.

The additional padding is indeed intentional, although it's not quite ideal. As you've probably noticed the Python versioning specification does have quite a few rules for normalising versions, but it still doesn't quite produce a single canonical form for all equivalent versions: 1.0a1 and 1.0.0a1 are both equivalent in terms of how versions are matched (see here) and are both in their normalised forms.

Padding out to at least three digits is something we do internally so that we have a consistent key by which to refer to a version. This is handy for things like the BigQuery dataset and for our internal databases, but it is certainly confusing. We do have some work in progress to preserve the upstream spellings of the version and present in the BigQuery dataset (potentially the other surfaces too if there's interest). It's complicated slightly by the fact that, for Python, there's not necessarily a single spelling because a single version might have multiple release artifacts (wheels for various platforms, sdists and so on), all of which might have a different way of representing the same version.

With all that in mind, I'm curious to know how exactly his is causing trouble for your tool (because we are looking to improve the situation). For now though if you're using the API, it should normalise the requested versions, so

curl https://api.deps.dev/v3alpha/systems/pypi/packages/verlib/versions/0.1

returns exactly the same response as

curl https://api.deps.dev/v3alpha/systems/pypi/packages/verlib/versions/0.1.0

but both responses will list the versionKey.version as 0.1.0.

from deps.dev.

Thanks for the detailed explanation. I was testing a big batch query using https://api.deps.dev/v3alpha/versionbatch and failed to check the response to see if the Python packages in question were there but with the added ".0" in the version. It should be fine.

from deps.dev.