Is there a technical reason why Pants doesn't write generated lockfiles to disk until all resolves have been successfully generated? In our monorepo, we have quite a few resolves, and it's frustrating when, say, 12 out of 13 generate fine but one fails — none of the successful ones get written to disk, so I end up needing to re-run the whole process with the failing one excluded. Curious if this is a deliberate design choice or just an implementation detail.

Not sure of the answer, but its noteworthy that some other things don't work this way: • if any docker image fails to build during a

package

command, the whole command will immediately stop. Any in-progress images are cancelled, but any that are already completed will have been written out. • When running tests, cache entries are written as tests are completed. Even if you Ctrl+C out, those that have been completed have already been written to cache.

Interesting, I didnt' know that. Seems like something we should fix

This is particularly bad with pip I guess. If it was uv or was super fast, then it's a bit more 🤷

If I had to choose what is delivered, I'd choose dep resolution via uv over writing out lock files independent of one another.

I see no reason not to write out the lockfiles that succeeded, this is likely an oversight

It would be a huge quality of life improvement if it were fixed.

Out of curiosity, what is failing in the lockfile generation?

In this case it was some constraint issue.

So, I think more generally - what you'd like to happen (and what I would naturally expect to happen) is that you only generate the missing/changed lockfiles. e.g. 12 succeeded, so they're all present, and you want to just run generation on the last.

We just manually generate them on a per-resolve basis via the --resolve arg to generate-lockfiles.

Where is the fun in that?! 😉