OK; one more question/shower thought. The way I've built the OCI backend allows for very little scripting by intention. Files are captured from pants and inserted verbatim into the output container. If you depend on a file, it'll have the same relative path in the container as it has in your workspace. BuiltArtifacts go to whatever their rel_path points to. Sane, but requires the user to have some mental map of their workspace - but that's fine as long as the container matches the workspace layout. Now; some things - at least Pexes, maybe more - don't output to a path that's relative to their source path.

src/py:bin

isn't

src/py/bin.pex

, it's

src.py/bin.pex

. And now I'm worrying that (a) all my artifact-producing backends are breaking some unwritten rules, and (b) I'm going to be in lots of weird situations because things will be in the unexpected locations for end users. Are pexes the odd ones out, or should most things follow this pattern? Is reality anything goes? Is there a utility for doing "address -> output root"?

I don’t have a great answer, but a few hints.. https://github.com/pantsbuild/pants/blob/21bd294486be89f49932c00fb575c9bec1bbb95c/src/python/pants/core/goals/package.py#L60-L91 and https://github.com/pantsbuild/pants/blob/21bd294486be89f49932c00fb575c9bec1bbb95c/src/python/pants/build_graph/address.py#L498 which I thought the output path field would use, but it didn’t..

I dug in a bit and found the original PR: https://github.com/pantsbuild/pants/pull/10899. I guess dotting prevents nesting different addresses when packaging,. So

src/py/foo:bin

and

src/py:bin

become

dist/
├── src.py/
│   └── bin.pex
└── src.py.foo/
    └── bin.pex

Instead of

dist/
└── src/
    └── py/
        ├── bin.pex
        └── foo/
            └── bin.pex

Which makes sense. So I guess I should follow this pattern. 🙂