Closed ericwb closed 6 months ago
There's almost no value in doing this. Twine and PyPI are actively implementing support for attestations
I know PyPI has been working on this for a while. Is it available yet? But yes, I understand how this can be redundant to have two destinations for artifacts and two ecosystems to attest them. It definitely feels like GitHub is attempting to a one-stop shop for all things code. I thought it was nice that you can attest the binaries with GitHub's CLI. Does Pip have plans for the same?
In any case, I can close this as I don't want to create confusion on where to obtain binaries and how to attest them.
Thinking about this more, totally agree. It's a bad idea to have two source repositories to fetch packages, each with it's own attestation.
We already publish to PyPI our packages. It is also useful to publish our binaries as artifacts here on GitHub. This action will build and publish release files as artifacts in the current release.
It runs whenever a new release is published.
This change also adds attestation of the artifacts so that users can verify the binary is the authentic one produced by our build.
More info on attestation here: https://github.blog/2024-05-02-introducing-artifact-attestations-now-in-public-beta/