https://pantsbuild.org/ logo
Join Slack
Powered by
One thing that I found to be surprising is that `S...
# plugins
h
One thing that I found to be surprising is that 
SyntheticTargetsRequest
completely ignores 
marker_filenames
option Is this intentional or an oversight?
f
SyntheticTargetsRequest
operates very early in the process of Pants determining what targets are available.
I might be missing something in your question; why would source root definition play into that?
Do you have a more particular use case in mind?
h
I'm looking into creating synthetic targets to reduce the BUILD file boilerplate which is practically the same for everything we do
Well, same for each "branch" in the file tree on our repo (Python and Go won't have the same BUILD file, obviously)
Provided there's a change we need to make, it'd be easier to do that once instead of editing a hundred BUILD files
f
Synthetic targets were primarily designed to allow plugins to inject targets which they want in the build graph for metadata and those targets may not necessarily need to be used by users directly. The current use cases are to represent lock files as targets.
The design goal was not for boilerplate redution.
Have you considered macros at all?
h
I understand, and have followed the Pants source code so I also understand how it works from the inside Macros are indeed a viable option, but they're less powerful as they're unaware of their surroundings, unlike synthetic targets which allow for some nice automation based on the file location which is made possible because we've got a very rigid repo structure
Would you strongly advice against "exploiting" synthetic targets this way?
I mean, I'm able to circumvent this by defining 
spec_paths_request
(even though it's not quite working for me right now 😅)
And also, I wanted to create a potential link with this effort (https://pantsbuild.slack.com/archives/C01CQHVDMMW/p1727705355068559) to have the correct resolves automatically inferred, and to my understanding synthetic targets are the only way to go here
f
Understood. The part I am still missing to understand is the connection to 
marker_filenames
. Are source roots somehow not available to your plugin?
(Or are you hitting some rule graph errors in trying to use the source roots-related rules? which can happen when there are cycles in the rule graph)
h
I would expect that if I used 
SyntheticTargetsRequest.REQUEST_TARGETS_PER_DIRECTORY
it will honor 
marker_filenames
but it doesn't
f
elsewhere in that file is:
Copy code
@dataclass(frozen=True)
    class SyntheticExampleTargetsPerDirectoryRequest(SyntheticTargetsRequest):
        path: str = SyntheticTargetsRequest.REQUEST_TARGETS_PER_DIRECTORY

        # Optional: (without it, only paths with BUILD files will be consistently considered)
        spec_paths_request = SyntheticExampleTargetsPerDirectorySpecPathsRequest
maybe switch to 
SyntheticTargetsRequest.SINGLE_REQUEST_FOR_ALL_TARGETS
and just return all of the targets at once (to avoid the "only paths with BUILD files will be consistently considered" part)?
and the logic behind that comment should probably be verified and also moved down to the docs for 
SyntheticTargetsRequest
h
1. I agree 2. I have considered using 
SyntheticTargetsRequest.SINGLE_REQUEST_FOR_ALL_TARGETS
but couldn't get it to work. All I'm getting back is 
SyntheticTargetsRequest(path='')
😕
f
Your hypothesis of a bug or design flaw seems strong to me. As a way forward, would you be able to submit a PR with a (failing) unit test in 
src/python/pants/engine/internals/synthetic_targets_test.py
for your use case? That way, we could debug and see precisely what is going on.
h
That's a very good approach for reproduction and paving the way for a potential fix I'm sold 🙂
4 Views
Open in Slack
PreviousNext
Powered by