<@U01PZK60W2F> &gt; I don't see the synthetic targ...
# development
b
@curved-television-6568
I don't see the synthetic targets affecting this scenario at all as it stands today. It could potentially evolve in that direction somehow, let's have a thread in Slack about that.
From https://github.com/pantsbuild/pants/discussions/17253 🧵
From the PR:
Synthetic targets are overridable. If you declare a target with the same address (and target type) as a synthetic target in a BUILD file it replaces the synthetic target, unless the
_extend_synthetic
target field value is true in which case only the field values provided in the BUILD file are overridden.
Theoretically, could we not have
python_sources
generate synthetic targets (does it now?). The user then has:
Copy code
python_sources(sources=["**/*.py", ...])
in the root. Then in
projectA/subdirX/BUILD
they define:
Copy code
python_source(
    name="IDK whatever it needs to be",
    source="myfile.py"
    dependencies=["./myresource.json"]
    _extend_synthetic=True
)
As a way to augment the generated
python_source
with the new dependency (in this case ADDING the dep to the list defined way above)
Thats the kind of world I wanna live in (minus the awkward
name
and
_extend_synthetic
). Perhaps
_extend_synthetic
becomes a new target type per target type: e.g.
extend_python_source
,
extend_shell_source
, ...
c
Ah, ok now I see where you got this idea from. Yeah, generated targets are not “synthetic” in this sense (yet?) not sure how hard that would be to change (I think pretty hard.. on the verge of reimplementing generated targets)
b
I know this is a dream of @happy-kitchen-89482’s as well. @witty-crayon-22786 is likely the 🧠 to answer that question
c
Another issue is that there’s still no way to explicitly declare a file target so it behaves the same as a generated one
👎 1