Output hashes from github action

[meeuw]

It's useful to have the hashes as outputs so this can be used for secure installs

[webknjaz]

Why?

[woodruffw]

Yeah, I think this needs some kind of rationale. @meeuw can you explain why you want this?

(For future reference, opening a PR like this with no description gives us very little information and therefore starts us with a negative disposition against merging.)

[meeuw]

I'm sorry I didn't added a description, I've updated to include a reference to secure installs.

I also think it's better using GitHub actions this way.

[woodruffw]

Okay, thanks for the context. Could you say a bit more about how you're expecting to use this feature with pip's hash-checking mode? Are you planning on feeding the output here into some kind of PR generation, or something else?

[webknjaz]

They are already printed out. I don't see the usefulness.

[meeuw]

Okay, thanks for the context. Could you say a bit more about how you're expecting to use this feature with pip's hash-checking mode? Are you planning on feeding the output here into some kind of PR generation, or something else?

This is useful for programs written in Python to generate a repeatable install when a release (on github) is done. One could run uv pip compile --generate-hashes to create a requirements.txt / pylock.toml file but the hashes for the package uploaded to PyPI would be missing, it would be nice if the pypi gh action would provide these hashes.

The requirements.txt can be used to download wheels from PyPI and the hashes can be validated before installing the wheels (pip wheel --require-hashes).

They are already printed out. I don't see the usefulness.

It would be nice to actually use the hashes, for example to generate a lock file after uploading them to PyPI.

Anyway, the hashes can also be recalculated in a follow up step, if you don't like this PR feel free to close it.

[webknjaz]

I'd recommend against adding more logic into the job with elevated privileges. As for exposing the hashes, it's not that simple — there's no restriction on uploading a specific project (at least when trusted publishing isn't in use), meaning somebody could stuff a bunch of various dists into the same folder and with a valid broadly scoped long lived API token upload to several different projects.

#97 also stumbles upon the same problem — if there's multiple projects, then we can't just export one output and hope for the best.

This is to say that exporting such information requires careful and intentional design (additionally to the problem of seemingly unrelated/undesired changes also bundled in this patch, like changing the input descriptions or moving the printing logic).

Just saying "secure installs" as a magic incantation doesn't really justify exposing these in a specific format w/o a clear plan on the proposed integration strategy. Hence, I can't accept this on a whim, without a well-thought redesign.

[meeuw]

I'd recommend against adding more logic into the job with elevated privileges. As for exposing the hashes, it's not that simple — there's no restriction on uploading a specific project (at least when trusted publishing isn't in use), meaning somebody could stuff a bunch of various dists into the same folder and with a valid broadly scoped long lived API token upload to several different projects.

I like the suggestion to simplify.

The action can be simplified even more if the printing of hashes is removed altogether. Consumers can use the outputs to print the hashes themselves.

#97 also stumbles upon the same problem — if there's multiple projects, then we can't just export one output and hope for the best.

This PR exports all outputs as a serialized string using \0 and : separators.

This is to say that exporting such information requires careful and intentional design (additionally to the problem of seemingly unrelated/undesired changes also bundled in this patch, like changing the input descriptions or moving the printing logic).

GitHub Actions outputs are (as far as I know) limited to strings only. Some serialization has to be done. I'm open to any other format.

Just saying "secure installs" as a magic incantation doesn't really justify exposing these in a specific format w/o a clear plan on the proposed integration strategy. Hence, I can't accept this on a whim, without a well-thought redesign.

I think there are currently three formats for hashes of pypi packages:

1. requirements.txt
2. pylock.toml
3. pretty-print table (as on pypi web interface and the current output from print-hash.py)
4. (my proposed) serialized string using \0 and : separators

I think all can be converted to each other with different difficulty.

Would you like it more if the current output from print-hash.py would be exported by the github action? I think newlines aren't allowed so these need to be escaped in some way.

Anyway, if it wasn't clear, the problem I'd like to solve is:

When you publish a program to PyPI with the intention for end users to install, how can you let them do a repeatable install using secure-installs?

You can use an utility like uv pip compile --generate-hashes to generate the hashes but this can only include the published program after it has been published to PyPI and has been distributed which could take some time.

The hashes are already calculated when print-hash is enabled and it would be nice if these can be used for this purpose.