11–20 of 61 posts
There seems to be a severe lack of hash pinning in "modern" software ecosystems. We figured out how to do it 20+ years ago with Git bringing hash addressed storage to the masses. Coming from a different background it was very surprising for me to see things like docker images, packages and github actions being updated at the whim of upstream registry. I much prefer the philosophy where builds are fully offline and pr…
There seems to be a severe lack of hash pinning in "modern" software ecosystems. We figured out how to do it 20+ years ago with Git bringing hash addressed storage to the masses. Coming from a different background it was very surprising for me to see things like docker images, packages and github actions being updated at the whim of upstream registry. I much prefer the philosophy where builds are fully offline and pr…
The release consists of one sdist and zero or more wheels. Until now you were able to upload additional wheels at later time.
There seems to be a severe lack of hash pinning in "modern" software ecosystems. We figured out how to do it 20+ years ago with Git bringing hash addressed storage to the masses. Coming from a different background it was very surprising for me to see things like docker images, packages and github actions being updated at the whim of upstream registry. I much prefer the philosophy where builds are fully offline and pr…
I’m not sure what this has to do with TFA: Python does have hash-pinning. TFA is not about modifying existing files on the index (PyPI doesn’t allow that), but about adding new files to a pre-existing release. But that doesn’t change the hash of older distributions on that release.
In concept why can’t the full set of files in a release be a single, one-way hash value, with both adding or releasing changing the hash value?
14 days still seems way too long to me. As a user I thought releases on pypi were immutable!
Earlier quoted context omitted.
I’m not sure what this has to do with TFA: Python does have hash-pinning. TFA is not about modifying existing files on the index (PyPI doesn’t allow that), but about adding new files to a pre-existing release. But that doesn’t change the hash of older distributions on that release.
I feel you’re quibbling over semantics here. In concept why can’t the full set of files in a release be a single, one-way hash value, with both adding or releasing changing the hash value?
You lock to the distribution instead of the release so your build doesn't have to download distributions for platforms you're not using.
14 days is still too long if you ask me. Releases should be immutable.
The time limit is needed because a release can contain different binary wheels for different architectures.
Consider the simplest case: your releases go out via GitHub Actions and separate wheels are built on the Windows, Linux, and macOS runners.
Those won't all end at exactly the same time, so you need a release window during which they can finish and upload their generated files.
That window used to be unlimited, now it's 14 days.
That might seem like a long time, but it means more manual release processes still have time to coordinate, or release processes that need access to less common hardware that might require queuing for a while.
14 days is still too long if you ask me. Releases should be immutable.
Published files within a release are immutable. The time limit is needed because a release can contain different binary wheels for different architectures. Consider the simplest case: your releases go out via GitHub Actions and separate wheels are built on the Windows, Linux, and macOS runners. Those won't all end at exactly the same time, so you need a release window during which they can finish and upload their gen…
14 days is still too long if you ask me. Releases should be immutable.
Published files within a release are immutable. The time limit is needed because a release can contain different binary wheels for different architectures. Consider the simplest case: your releases go out via GitHub Actions and separate wheels are built on the Windows, Linux, and macOS runners. Those won't all end at exactly the same time, so you need a release window during which they can finish and upload their gen…
Earlier quoted context omitted.
I’m not sure what this has to do with TFA: Python does have hash-pinning. TFA is not about modifying existing files on the index (PyPI doesn’t allow that), but about adding new files to a pre-existing release. But that doesn’t change the hash of older distributions on that release.
I feel you’re quibbling over semantics here. In concept why can’t the full set of files in a release be a single, one-way hash value, with both adding or releasing changing the hash value?
(Also: we’d need to determine what it even means to hash a set of files. Do we order by canonicalized filename, by upload time, etc. Each of these has surprising implications!)
Edit: to be clear, it’s not ideal or fully intentional that uploads to PyPI are not atomic. But it’s the status quo and any change will take years.