Skip to content

Conversation

@woodruffw
Copy link
Member

@woodruffw woodruffw commented Nov 13, 2025

Summary

Still working on this.

TL;DR: This makes uv publish behave like twine upload: when a user does uv publish dist/* and dist/* includes attestations, we now group those attestations with their matching distribution and include them in the upload. This changes the behavior from the previous behavior, which silently skipped these (since they don't match the distribution filename format).

This is a step towards #15618: we don't produce attestations within uv itself yet, but this allows uv to upload them if they're already present as part of the distribution paths.

Test Plan

I've broken the uv-publish crate's functionality for collecting upload inputs a part a bit to make testing of the grouping logic easier; files_for_publishing is now group_files_for_publishing, with an interior helper (group_files) that does no I/O or filesystem ops. I've added unit tests for that inner helper to confirm our matching/grouping works as expected and doesn't regress on other publishing tests.

Separately, it'd be nice to have some kind of integration test with an index that supports attestations, like PyPI or TestPyPI. I'll need to think a bit about how best to do that 🙂

Signed-off-by: William Woodruff <[email protected]>
@woodruffw
Copy link
Member Author

Flagging one thing: unlike twine upload this currently sends attestations unconditionally if they're present, which may not play super well with various indices (they may reject the attestations form part rather than silently skipping it). I'll need to add this to our upload tests.

Signed-off-by: William Woodruff <[email protected]>
@woodruffw
Copy link
Member Author

We'll want documentation for this as well. Let me know if you need help finding a place for it.

Thanks! I'm guessing maybe this belongs under guides/package.md, i.e. the building/publishing guide? Longer term it probably also makes sense to mention/describe in the GitHub integration guide, although maybe not until attestation generation happens in uv itself.

@woodruffw woodruffw temporarily deployed to uv-test-registries November 20, 2025 15:34 — with GitHub Actions Inactive
@woodruffw
Copy link
Member Author

I added a small section to the packaging guide, but I'm not sure how much detail to include. One thing that made me realize is that we don't really expose a knob for this at the moment -- maybe it makes sense to add --no-attestations / UV_PUBLISH_NO_ATTESTATIONS for non-supporting indices that misbehave and fail rather than ignoring attestations?

@konstin
Copy link
Member

konstin commented Nov 20, 2025

The knobs and their names sound good

Signed-off-by: William Woodruff <[email protected]>
Signed-off-by: William Woodruff <[email protected]>
@woodruffw woodruffw temporarily deployed to uv-test-registries November 20, 2025 16:34 — with GitHub Actions Inactive
@woodruffw woodruffw requested review from konstin and zanieb November 20, 2025 16:54
@woodruffw woodruffw self-assigned this Nov 20, 2025
Comment on lines +191 to +192
`uv publish` does not currently generate attestations; attestations must
be created separately before publishing.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we link or suggest how they would be created?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The wrinkle here is that there's no good way to do this currently 😅 -- we could point users to pypi-attestations as a DIY approach, but that's a glue package that isn't really intended for direct usage.

(What gh-action-pypi-publish does is have a helper script that uses the pypi-attestations APIs.)

One option here would be to create astral-sh/pypi-attest as an action, which we'd then recommend at least until we have in-client attesting. That would only take me an hour or two to build.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or improvement to existing functionality

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants