@happy-kitchen-89482 do you remember the thinking behind https://github.com/pantsbuild/pants/pull/15068 ? w/ pants 2.15+ I thought

./pants export --resolve=...

only deleted the virtualenv(s) for the selected resolves, but it looks like every call deletes the entire

dist/export

tree. I made https://github.com/pantsbuild/pants/pull/17711 to narrow what it deleted from resolve to resolve+python version only to realize I was way off base. (It delete all exports every time, not just the selected resolves) Would you be opposed to progressive exports? Export one resolve and then another without deleting the first?

So the actual issue solved by #15068 was https://github.com/pantsbuild/pants/issues/14779 and that could also have been solved by passing

--force

to the Pex

venv

tool here: https://github.com/pantsbuild/pants/blob/11bca3f57eddc82e773e8aef627f7a7442b8692d/src/python/pants/backend/python/goals/export.py#L188-L198 That would only delete a re-export which sounds like what you want and seems sane to me.

Either option (selectively delete before regenerating, or regenerate with

--force

) seem fine to me. The original deletion was probably too aggressive

The core goal is supposed to be language agnostic. So, this is a question of responsibility: Should the language specific backend be responsible for deleting the old dir? (Thus, use

--force

) Or should the core goal selectively delete before regenerating?

Does the core goal have enough information to selectively delete?

Yes. Core knows this dest directory. Today the python backend passes the resolve's export directory for dest, so, core could delete the resolve export dir. I assumed that's how it worked, so I wrote https://github.com/pantsbuild/pants/pull/17711 to make dest include the interpreter version as well.