You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As described in pypi/warehouse#12483, there is no limit on the total character length of the version specifier. This can lead to potential issues, either due to deliberate abuse or by accident, if the version is extremely long and hits file name or file path length limits on the filesystem.
Out of curiosity I dug into this a bit, with google big query, for all packages in the-psf.pypi.distribution_metadata the summary is:
count 7.902727e+06
mean 6.598360e+00
std 3.552846e+00
min 1.000000e+00
25% 5.000000e+00
50% 5.000000e+00
75% 7.000000e+00
99% 2.200000e+01
max 2.350000e+02
Out of 7,902,727 published package versions there are:
337,624 over 16 characters
697 over 32 characters
407 over 64 characters
It's kind of surprising to me that hundreds of releases have such long versions 😕 either way, overall 99.991% of versions have less than or equal to 32 characters.
There's actually a discussion about this on semver semver/semver#304 but I don't think any limit was set in the specification, although practically there is a limit as major/minor/patch get parsed as integers and JS' max safe integer is 9007199254740991, which in total means the max string length is 50 characters for node js.
PEP 440 says that "the versioning specification may be updated with clarifications without requiring a new PEP or a change to the metadata version", IMO adding a 'sensible' (whatever that may be) limit to the total character length of the version specification would fit into this.
The text was updated successfully, but these errors were encountered:
Adding a limit seems sensible but the PEPs repo isn't the right place to have this discussion. I'd recommend opening a discussion at https://discuss.python.org/c/packaging/14, and when consensus develops we can update the PEP and/or the packaging spec (not sure whether there's a corresponding spec for this PEP).
As described in pypi/warehouse#12483, there is no limit on the total character length of the version specifier. This can lead to potential issues, either due to deliberate abuse or by accident, if the version is extremely long and hits file name or file path length limits on the filesystem.
So far this only seems to have been encountered within projects which are mirroring PyPA (pypa/bandersnatch#1200, pypa/bandersnatch#1228, tuna/issues#1538), likely because no major projects have versions long enough to cause an issue.
Out of curiosity I dug into this a bit, with google big query, for all packages in
the-psf.pypi.distribution_metadata
the summary is:Out of 7,902,727 published package versions there are:
It's kind of surprising to me that hundreds of releases have such long versions 😕 either way, overall 99.991% of versions have less than or equal to 32 characters.
There's actually a discussion about this on semver semver/semver#304 but I don't think any limit was set in the specification, although practically there is a limit as major/minor/patch get parsed as integers and JS' max safe integer is 9007199254740991, which in total means the max string length is 50 characters for node js.
PEP 440 says that "the versioning specification may be updated with clarifications without requiring a new PEP or a change to the metadata version", IMO adding a 'sensible' (whatever that may be) limit to the total character length of the version specification would fit into this.
The text was updated successfully, but these errors were encountered: