I noticed that the pex builder seems to depend on the output filename (

<http://path.to|path.to>.some/target.pex

), which seems moderately unfortunate from a caching perspective. https://github.com/pantsbuild/pants/blob/1f4b040ba4e3e875d1b08c6c1d6bbbccc6538f0e/src/python/pants/backend/python/util_rules/pex.py#L572-L573 For instance: if a build target is renamed, or if multiple targets end up building the same PEX (e.g. multiple

include_sources=False

pexes that happen to have the same set of 3rd party requirements would be convenient to share from each other). Is that output path doing something other than moving the file around? As in, could it be fixed for the process invocation, and the renaming managed outside?

Yup, that would work just fine.

Hm, I see

AddPrefix

and

RemovePrefix

, but my searches for "move", "rename" don't find anything. I suppose I could run a subprocess with

MvBinary

, or

CreateDigest

with an appropriately adjusted bunch of

FileContent

objects. Any tips?

I'd add a new intrinsic to rename. Having to resort to a shell + mv on the system seems unfortunate. Having a full suite of digest manipulation tools seems to be par for this sort of system. You probably want to consult Stu though. Afaict his brain encodes the principles of when to draw the line. I know he has not like the idea of making zip / unzip (plus tar, etc) intrinsics in the past and these aren't super far off from this.

Thanks, will do

There's a ticket about combining the path shenanigans intrinsics into one. So this might just break the camels back 😁

No sure if this is going in the same direction or not, but it would be nice if the "output_name" could be set in independently of the output_path for all packageable things, so they could all easily be set to

foo-VERSION.tar.gz

Porque no los dos?

I wasn’t planning on changing the user facing API, just tweaking the internals for improved cacheability… but what you say certainly sounds worth a feature request issue to me

spinoff feature request: https://github.com/pantsbuild/pants/issues/18659