witty-crayon-22786
02/04/2022, 6:48 PMoverrides
while finalizing the syntax with @
first, followed by #
. after thinking it through, i agree, and have updated the design doc to swap those back, and to add a section on the topic#
syntax isn’t going to allow arbitrary syntax (which i had been thinking might be one of its usecases, with the git
case), then does it really need to be a separate syntax from :
? or should we preserve the model that we have via CAOFs that generated targets are still targets, without necessarily needing an association with their generator?:req
to #req
#
allows more internal syntax than :
does… because it supports URLs for go
.hundreds-father-404
02/04/2022, 7:29 PM:generator
snippet to locate where the generated target comes from. It also enforces disambiguation naturally
Otherwise we need "address-less target generators" I think: https://docs.google.com/document/d/17XvhHlx8jBn4K9qFRZPe7qaKJQjTfiKMKYRubnzWxjA/edit. Which involves lots of discussion + implementation workwitty-crayon-22786
02/04/2022, 7:30 PMhundreds-father-404
02/04/2022, 7:34 PMwitty-crayon-22786
02/04/2022, 7:34 PMhundreds-father-404
02/04/2022, 7:37 PMwitty-crayon-22786
02/04/2022, 7:37 PM#
to mark “completely synthetic targets”, if we start creating targets from scratch.hundreds-father-404
02/04/2022, 7:38 PMi suppose that it also might eventually be useful for # to mark “completely synthetic targets”, if we start creating targets from scratch.Meaning you want to reserve
#
for a different future use?:tgt
suffix vs. leave it unchangedwitty-crayon-22786
02/04/2022, 7:39 PM#
marking a target that doesn’t actually exist in a BUILD file. so if you generated a “default” scala toolchain Target, for example, you’d generate it with a #
address like //#default-scala-toolchain
or something.hundreds-father-404
02/04/2022, 7:42 PM//:reqs#Django
rather than //:Django
, I do think there's some value to being able to easily trace where something is coming from. For example, debug_hint
with stacktraces.
And then, again, avoids the problem of //:reqs#Django
vs //:poetry#Django
in the same repo. Which your design doc points out is an actual real issue, that macro authors etc need to reason about address disambiguationwitty-crayon-22786
02/04/2022, 7:42 PM#
aren’t really that bad… the only character you’d be forced to escape would be @
hundreds-father-404
02/04/2022, 7:44 PMcurved-television-6568
02/04/2022, 7:46 PMwitty-crayon-22786
02/04/2022, 8:26 PMoverrides={'t.py': {"resolve": parameterize(..)}
, there are challenges: https://docs.google.com/document/d/1mzZWnXiE6OkgMH_Dm7WeA3ck9veusQmr_c6GWPb_tsQ/edit?disco=AAAAVIAE4Dssrc/python:example@resolve=one#generated@resolve=two
)hundreds-father-404
02/04/2022, 8:30 PMmaking target generators “not real targets”… i.e., not giving them fields at allI've roughly proposed that in the past https://github.com/pantsbuild/pants/issues/13086, but we can't to keep the alias mechanism +
./pants peek
witty-crayon-22786
02/04/2022, 8:32 PMhundreds-father-404
02/04/2022, 8:34 PMpython_sources(
resolve=parametrize("a", "b")
overrides={
"utils.py": {"resolve": "c"},
"another.py": {"resolve": parametrize("c", "d")},
},
should result in:
dir/f.py@resolve=a
dir/f.py@resolve=b
dir/utils.py
dir/another.py@resolve=c
dir/another.py@resolve=d
and your “generators are all macros” proposal,the first drafts of https://docs.google.com/document/d/1HpJn2jTWf5sKob6zhe4SqHZ7KWBlX4a6OJOwnuw-IHo/edit#heading=h.holikof0ozs1
witty-crayon-22786
02/04/2022, 8:35 PMhundreds-father-404
02/04/2022, 8:36 PMwitty-crayon-22786
02/04/2022, 8:37 PMhundreds-father-404
02/04/2022, 8:38 PMwitty-crayon-22786
02/04/2022, 8:39 PMpeek
, etc.hundreds-father-404
02/04/2022, 8:41 PMwitty-crayon-22786
02/04/2022, 8:41 PMhundreds-father-404
02/04/2022, 8:43 PMwitty-crayon-22786
02/04/2022, 8:44 PMhundreds-father-404
02/04/2022, 8:45 PMtags
exists both on the generator itself and all generated targets. So I don't think the above proposed semantics will be that confusing. The docs try to push really hard that core message about atom targets being what matterswitty-crayon-22786
02/04/2022, 8:45 PMhundreds-father-404
02/04/2022, 8:47 PMparametrize("a", "b")
in the ./pants peek
for it. (although JSON serialization is a thing)TargetGeneratorMixin
to the Target
classwitty-crayon-22786
02/04/2022, 8:52 PMI’m open to considering that, although not sure it’s necessary? I guess it would be if you parametrize one of its fields..I wonder if we could work around that another way, like literally showingÂthat, and the Field itself must actually be constructed (with some value) in theÂparametrize("a", "b")
 for it. (although JSON serialization is a thing)./pants peek
hundreds-father-404
02/04/2022, 8:55 PM./pants peek
on target generators because it lets you programmatically understand your BUILD files. But I don't think that is as crucial as overrides
working as described above