having a form of `./pants list` which also prints ...
# general
a
having a form of
./pants list
which also prints the stringified targets sounds extremely useful for debugging codegen tasks or context-aware object factories -- am i missing any existing facilities to do this?
a
We definitely don’t have this…
bazel query --output=build //some:target
does this really nicely, and is super useful, so I would strongly support such a thing if we can make it work well 🙂
a
!!!!!!
a
(In particular, as well as being useful for codegen, it expands globs and lists
srcs
as a literal list of source files, which is so helpful!)
a
w
hm... what does "stringified targets" mean here?
a
PythonTarget(address=..., compatibility=..., ...)
w
mm
iirc Yi worked on a goal to do this? or had an intern do it?
a
Oh, I didn’t mean `Target`s, I meant BUILD-equivalent snippets
w
but it basically just echoed the target definition from the BUILD file
yea, that.
a
that'd be better i was just thinking of hacking something up
w
...
Copy code
$ ./pants help buildozer

buildozer options:
Enables interaction with the Buildozer Go binary

--buildozer-add-dependencies=<str> (default: None)
    The dependency or dependencies to add
--buildozer-command=<str> (default: None)
    A custom buildozer command to execute
--buildozer-remove-dependencies=<str> (default: None)
    The dependency or dependencies to remove
?
a
Buildozer won’t be aware of computed values, though, only literals already in BUILD files
a
i'm not planning to use buildozer
a
I’m imagining:
Copy code
$ cat some/BUILD
my_codegen_target()
$ ./pants show some:
resources(
  name = "some",
  sources = ["foo", "bar"],
)
a
i'm already wary of outputting target-equivalent code because then people would just redirect it to their BUILD file and use that
a
I think that’s a positive, no?
“I have some macros, I’d like not to have my macros, so I expanded my macros and now my macros are gone” is a useful use case
a
why don't you want macros?
a
I don’t need them any more?
w
the python repr of a Target isn't really a public API per-se... the symbolic name of the target is one folks are familiar with
a
i was under the impression macros are a good thing
a
They’re a tool; if a user wants to use them, that’s great, if they don’t, we shouldn’t make it hard for them to not?
But yeah, arbitrary users of pants shouldn’t need to grok a whole internal Python API when they’re used to interfacing with BUILD files… It’s a really weird abstraction leak…
a
i don't understand the problem description
w
me neither, heh.
a
it seems like you are describing a situation where a user is making macros and then throwing them away
w
i don't understand the original usecase
a
My use-case literally today was “I screwed up my macro, and I need to work out how”, and being able to see the exact BUILD file which my macro was generating was super helpful to debug…
w
anywho.
a
i don't understand then what "now my macros are gone" is referring to
a
Separate use case: I have some macros for historical reasons. Those reasons no longer apply. It’s super easy to delete them if I can just output the expanded BUILD files and overwrite them with the literal output the macros expanded to.
a
i see that the opposite way
i don't understand why your macros go out of date but the literal output doesn't, i would assume macros are used in order to generate targets which aren't tied to a specific version of a tool for example
w
with regard to the original usecase: the "synthetic target" concept will likely go away in v2, which would mean that there may no longer be a BUILD file representation of any buildable thing
so i would suggest holding off on doing something like this until after some of the target API design from 4535
a
that statement makes me uneasy but with more context i might be great with it
w
well, see the other thread re SimpleCodegenTask
...for the context
a
i mean i wasn't thinking about anything like this at all after the first comment actually,
./pants --query
is more like it https://github.com/pantsbuild/pants/issues/6501#issuecomment-452069677
yes i saw you had commented and hadn't checked it yet, thanks
a
By macro I mean something like, in a BUILD file:
Copy code
def make_my_targets():
  for i in range(100):
    junit_test(
      name = "test_{}".format(i),
      sources = ["Test{}.java".format(i)]
    )

make_my_targets()
with some arbitrarily complex code in the function. Say I no longer need the flexibility of generating lots of these targets; for whatever reason my requirements change and there will always be exactly one of these targets. Being able to change my loop limit to 1, and then run
./pants show some:target
is much nicer than me needing to manually execute the code by hand to write down what gets generated by the arbitrarily complicated code…
a
that's exactly the kind of thing i think we would prefer to have codified, canonicalized, and integrated as a first-class citizen into the rest of the build as a rule
a
I’m not sure what that means
a
this looks like awfully complex code to have in a BUILD file
a
And yet it’s code people have in BUILD files today!
a
and i would think we wouldn't want to make functionality explicitly to make it easier to write one-off for loops in BUILD files instead of making it easier to write rules to do the same?
a
(I’m not saying I want people to write complex code in BUILD files, I’m saying this is a feature I’ve found useful in the current day in other tools, for reasons that currently apply equally to pants…)
a
other tools don't make it easy to write rules to do the same
maybe pants doesn't yet either, but there is at least a light at the end of the tunnel here
a
Bazel certainly does make it easy to do so, but it also has a concept of macros it will expand, because they’re a mind-numbingly simple tool that users can pick up without having to learn any new concepts…
(Regardless, I agree with Stu that we should design a target API before we try to refine how people make targets 🙂)
a
so are shell scripts
a
Yes; many people write shell scripts which form part of their build because they’re simple, too… We have a few thousand lines of them in the pants repo…
w
(sidenote: i am crawling through reviews between release cleanup attempts!)
a
and i have a cargo ruleset which i was advised to look at later and not finish up yet which removes a ton of those
characterizing rules as something people won't want to learn to use when it can make their builds significantly faster, more repeatable, and most importantly readable seems like it doesn't give enough credit to people who are interested in working on the build. allowing rules as first-class citizens means a repo can have one person maintain rules every so often depending on repo size, and everyone else can have all the advantages of that, instead of amortizing the (greater) cost of everyone who wants to do something not supported in base pants having to hack together some logic in their own BUILD file, likely under a deadline when they're trying to get something else done. that is where the benefits of rules come into play.
a
I look forward to the rules API which is quicker for someone to learn than the snippet I posted above...
a
that's why i mentioned the difference in amortized time above, because "quicker for someone to learn" depends on what they are trying to accomplish. to quote a ridiculously overused argument: "simple vs easy"
w
both macros and rules are useful. i don't think either of you are saying that either are not useful.
a
Yeah, and there are definitely a non trivial number of users who never need more power or complexity than the above.
Yeah, making rules very simple to grok and write is something I'm firmly behind as well :)
a
i'm assuming that the users that don't need more power or complexity than the above still need more power or complexity than what is currently available in a BUILD file, or they wouldn't be writing for loops.
so that complexity and/or power has to involve code somewhere, and it would be nice if we could make that a process of writing a rule instead of writing a for loop that then gets thrown away or bitrots