https://pantsbuild.org/ logo
#plugins
Title
# plugins
g

gorgeous-winter-99296

03/16/2023, 8:42 PM
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"?
g

gorgeous-winter-99296

03/18/2023, 5:01 PM
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
Copy code
dist/
├── src.py/
│   └── bin.pex
└── src.py.foo/
    └── bin.pex
Instead of
Copy code
dist/
└── src/
    └── py/
        ├── bin.pex
        └── foo/
            └── bin.pex
Which makes sense. So I guess I should follow this pattern. 🙂
It doesn't seem overly useful for e.g. pexes, but for something like my markdown backend which dumps out 100's of files for a large set of docs... yeah. A bit more safe. 😛
2 Views