[woodruffw]

Files are immutable on PyPI, releases are not (because releases are comprised of a set of files, and files are uploaded one by one).

This is unintuitive, but the TL;DR is that files will never change on PyPI, but (previously) a user could upload a new file to a release years after their last upload to that release. This has some legitimate use cases (like allowing people to support new Python versions without bumping a package’s version), but also makes introduces challenges around locking and release security that are elaborated in the thread linked by the blog post.

I agree this could probably be ratcheted down from 14 days over time, though.

[akerl_]

Worth noting, because I think it’s confusing some folks on this comments page, that “file” here is “a wheel for a platform” or “a complete sdist”, not “each individual .py file in a release”

You can’t go back later and add “evil.py” to a bunch of existing release files, but you could previously go find a bunch of releases that didn’t have arm64 files, publish malicious ones, and use that to catch people using those versions on arm64 systems

[PunchyHamster]

> (like allowing people to support new Python versions without bumping a package’s version)

...why Python is just breaking compatibility so bad with new version it needs that ?

[woodruffw]

It doesn’t. It’s really only relevant if you use version-specific APIs/ABIs in wheels containing machine code. Pure Python wheels don’t generally need this.