Avoid broken build artifacts on build failure

[bybrooks]

Summary

Fixes #17232

When uv build fails (e.g., due to missing __init__.py), partial distribution
files were being left in the dist/ directory.

Changes

• Use NamedTempFile to write build output to a temporary file first
• Only persist the file to the final location on successful build
• If build fails, the temporary file is automatically cleaned up
• Added Error::Persist variant for handling persistence failures

Test Plan

Added no_partial_files_on_build_failure test that verifies:

1. build_source_dist fails when __init__.py is missing
2. build_wheel fails when __init__.py is missing
3. The dist/ directory remains empty after both failures (no partial files)

[EliteTK]

Thanks for this!

I left a few comments, I'm somewhat new here so my colleagues might have additional comments.

It would be good to add an integration test in crates/uv/tests/it/build_backend.rs to check the error messages.

---

There's something to consider, this changes the behaviour for handling pre-existing built files. Currently we start by overwriting them. This means that in the case of a failure, the existing files are lost and replaced with incomplete new ones. Now we are only overwriting the files if we succeed. Personally it's what I would expect here.

But when reporting errors, the user will see something like "Failed to ... dist/project-0.1.0-py2.py3-none-any.whl", implying the specified file was not able to be built, but if they check, they will see there is a file there.

Could this be confusing and should we do something about it? I see a couple of options aside from just leaving it as is:

• Delete any target files before attempting to write the new ones
• Mention in error reporting that the (or we could make it easier for ourselves and just say "any") existing file has not been overwritten

[bybrooks]

@EliteTK
Thank you for the feedback!

Delete any target files before attempting to write the new ones
Mention in error reporting that the (or we could make it easier for ourselves and just say "any") existing file has not been overwritten

I'll go with Delete any target files before attempting to write the new ones.

This ensures a consistent state where the existence of the target file directly indicates a successful build.

I'll implement this by deleting the target file (if it exists) before creating the temporary file.

[EliteTK]

@bybrooks regarding the deleting - feel free, although once we discuss this further, we might not want to go with that option, so also feel free to wait for a verdict there. There is no rush at least on my end.

Main issue is that everyone else is on annual leave :)

[codspeed-hq]

CodSpeed Performance Report

Merging #17276 will not alter performance

_{Comparing bybrooks:bybrooks/atomic-build-output (bc49b6e) with main (82a6a66)}

Summary

✅ 5 untouched

[konstin]

There's something to consider, this changes the behaviour for handling pre-existing built files. Currently we start by overwriting them. This means that in the case of a failure, the existing files are lost and replaced with incomplete new ones. Now we are only overwriting the files if we succeed. Personally it's what I would expect here.

But when reporting errors, the user will see something like "Failed to ... dist/project-0.1.0-py2.py3-none-any.whl", implying the specified file was not able to be built, but if they check, they will see there is a file there.

Could this be confusing and should we do something about it? I see a couple of options aside from just leaving it as is:

* Delete any target files before attempting to write the new ones

* Mention in error reporting that the (or we could make it easier for ourselves and just say "any") existing file has not been overwritten

Deleting the target file(s) before starting the build seems to be the easiest. No strong opinion, users shouldn't rely on a specific the state of dist/ after a non-zero exist code anyway.

[bybrooks]

Deleting the target file(s) before starting the build seems to be the easiest. No strong opinion, users shouldn't rely on a specific the state of dist/ after a non-zero exist code anyway.

Thanks for the reply.
I’ve implemented the logic to delete existing files before the build starts. （ bc49b6e）