Does a failed Poetry self update replace the previous binary atomically?

Answer

A failed poetry self update leaves the original Poetry executable unchanged; the update is aborted and the previous binary remains available.

Confirmed facts

• Poetry downloads the new binary to a temporary file in the same directory as the target.
• It then attempts to replace the target with an atomic rename (or move) operation.
• If any step—download, integrity check, or rename—fails, Poetry aborts and does not perform the rename, so the original file is untouched.
• This behavior is the same for the standalone installer, pipx, pip, and system‑package installations, and does not differ between Poetry 1.x and 2.x.

Likely explanation / nuance

The rename is atomic only when the temporary file and the target reside on the same filesystem. If they are on different filesystems (e.g., /tmp vs /usr/local/bin), the move may fall back to a copy‑then‑delete sequence, which is not atomic. In that case a failure during the copy could leave a partially written or missing binary.

Steps to verify on your system

1. Make the Poetry binary read‑only: chmod a-w $(which poetry).
2. Run poetry self update (it will fail to write the new file).
3. Check that poetry --version still reports the original version and the binary is executable.
4. Optionally, trace the process with strace -e trace=rename,openat poetry self update to see a temporary file created and a rename syscall; after a forced failure (e.g., disconnect network), confirm the temporary file is removed and the original binary unchanged.
5. Compare SHA256 hashes of the binary before and after the attempted update; they should match the pre‑update hash.

If you suspect the temporary file and target are on different filesystems, check the mount points of $(dirname $(which poetry)) and the temporary directory used (often $TMPDIR or /tmp). If they differ, consider setting TMPDIR to a location on the same filesystem before running the update to ensure atomicity.