9 ms·
14 days still seems way too long to me. As a user I thought releases on pypi were immutable!
by lexicality 2mo ago
14 days still seems way too long to me. As a user I thought releases on pypi were immutable!
- woodruffw 2mo agoFiles 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_ 2mo agoWorth 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 2mo ago> (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 2mo agoIt 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.
- kzrdude 2mo agoHow it works in practice is that some release flows add wheels for different platforms, as they get ready, separately.