https://pantsbuild.org/ logo
Join Slack
Powered by
Proposal for simplifying macros in BUILD files: <h...
# general
a
Proposal for simplifying macros in BUILD files: https://docs.google.com/document/d/1mtkZGB6nZochxbbKx1zUzoJ1H3Jh_j4lEso586UPreE/edit - comments very welcome! (Currently accessible by pants-devel@, but drop me a message with your email address if you don’t have permission and want it)
@hundreds-father-404 @happy-kitchen-89482 @enough-analyst-54434 in particular I suspect may be interested
💯 1
h
This is independent of the Target API, right? That is, macros are evaluated before the Target API ever kicks in? All a macro does is reads a symbol like 
python3_library
, then calls its macro thing to convert it into another symbol 
python_library
, and that’s when the Target API kicks in?
a
Exactly
👍 1
But it may slightly simplify the Target API because it separates this “preprocessing” to happen cleanly in a separate layer
(Right now 
TargetMacro
ends up creating an object of a different type which can confuse things)
h
One more thing I’m still confused by. Is this both 
objects
and 
context_aware_object_factories
or only 
context_aware_object_factories
? I think I sort of get what 
objects
are now - a collection of values that aren’t quite targets, e.g. an 
Artifact
config. They can be any arbitrary class and the symbol in BUILD files is the constructor
a
This would be some 
targets
and some 
context_aware_object_factories
, but probably not any 
objects
, I think? But I’m a bit fuzzy on them
h
cc @witty-crayon-22786 on if 
objects
ties into macros
w
objects are literally just "a python symbol"
no magic.
h
Are they used for macros?
w
they cannot be, because they cannot touch any other BUILD symbols.
💯 1
h
Awesome. So this is only to replace 
context_aware_object_factories
, correct? And the macros can either be creating Targets (V1 or V2) and objects
w
yea.
👍 1
here is another way to think about "objects" maybe... they're basically just "imports": "put this symbol in the namespace"
h
Cool, thank you. @average-vr-56795 it might help to put a short snippet about this distinction in your doc
they’re basically just “imports”: “put this symbol in the namespace
Sure, but where it’s tricky is that 
targets
and 
context_aware_object_factories
do the same thing of “putting this symbol in the namespace”, so that is not unique to 
objects
w
they do not though.
targets and macros are evaluated in a context where they can define targets in the namespace
a
@hundreds-father-404 I just tried to clarify in the paragraph starting “Long-term” 🙂
💯 1
w
targets are wrapped up in order to do that via a sideeffect when they are called
macros currently (
context_aware_object_factories
) get a 
context
object that they can call to define targets
@hundreds-father-404: does that make sense? basically, macros and targets both are intended to run for the sideeffect of declaring targets... they don't actually return anything
h
Are you saying this is valid:
Copy code
x = setup_py(...)
but this is not?
Copy code
x = python_tests()
w
correctish. the second thing will just have 
None
in 
x
, i think
👍 1
h
Okay, I’m a bit thrown off by that because John showed me the parser experiment where 
x = python-tests()
is valid
w
which is why 
python_tests
and other targets are just top-level calls. the sideeffect is what actually does something.
ah, yes. good.
(ftr: bazel apparently also uses sideeffects here)
and yea, John probably explained that those experiments (tried to?) explore a world without macros, where composition occurred in other ways
h
He didn’t fully explain it. More pointed to the experiment as evidence that there are multiple ways to solve the problems we’re working on. (Context was dropping build file targets)
w
mm. that's related i think, yea.
a
I’m hoping to get this implemented soon-ish, any firm thoughts/preferences/objections? @hundreds-father-404 @happy-kitchen-89482?
h
Are you planning on proposal 1 or 2?
2 seems fine to me
a
I’m happy with either - do you have a strong preference?
h
More generally, how does this interact with the v2 target API? How would a custom targets file define that 
fancy_java_library
in practice?
1 is probably better for small-medium repos, 2 is probably better for large repos
Is my guess?
a
I think this is orthogonal to the v2 target API - this is effectively allowing installing preprocessors for BUILD files
w
twitter has biased toward 1-like approaches, because it drives consistency through the repo
👍 1
a
So if you need the power of the target API, you’d write a full target, but if you just need to change around some args for existing targets, you’d effectively use python as a preprocessor
👍 1
w
tangent, but: bazel does all extension via these types of imports of bzl files, whereas pants is in a world where rules are never likely to be per-directory
(maybe not tangent)
rules, plugins, etc being repo-wide should probably bias toward BUILD syntax being repo wide.
h
ok, makes sense
2 Views
Open in Slack
PreviousNext
Powered by