Delete Pipfile.lock as late as possible

When updating Pipfile.lock, the old version is deleted before anything happens. If the update process fails (maybe because one Ctrl+C’s it because of a mistake, or it’s taking too long, or it crashes, etc.), then one is left with no lockfile.

Could the behaviour be changed so that the lockfile deletion is performed immediately before the serialisation of the new content? (FWIW, I’d be happy to attempt a PR for this.)

I guess two rationales for the current behaviour:

1. Your Pipfile.lock should be in Git. Yes, but it still sucks if you’re doing a sequence of new package installs/etc. and haven’t committed your work.
2. The update of the Pipfile.lock should be consistent with the current state of the virtualenv. I’d buy that, but the current behaviour (no lockfile) doesn’t strike me as better 😉.

---

Steps to replicate

1. Start with an existing Pipenv environment (i.e. you have a working Pipfile/Pipfile.lock).
2. Run pipenv install <any_dep_that_takes_a_long_time>.
3. Hit Ctrl+C before it’s finished.

[uranusjr]

+1 from me on the atomic file replacing part. I’ve always disliked how Pipenv deletes the lockfile and then fails to lock, personally. Nothing wrong technically, but is a bit expectected from a UX perspective.

[wichert]

This would be really helpful for us. I am currently in a location where the network is very slow, and I keep seeing developers hit a download timeout, not noticing Pipfile.lock disappeared, running pipenv install again and then noticing all kinds of unexpected upgrades happened.