Hello! One of the main feedback from the Community Survey y'all helped with (thank you!) was how BUILD files continue to be a barrier to adoption. Even w/ dep inference and

./pants tailor

, there's still too much boilerplate and it's particularly hard to change metadata for a couple files because you have add new targets and update the

sources

field for old ones. Not intuitive / a common gotcha, and lots of boilerplate We agree! We've wanted to solve for a year, and I think this proposal would do it without introducing any breaking changes. https://docs.google.com/document/d/1bcQRJazx6ODKc0PZRUgPx_bqHc6XurpBawTMD2zhtAk/edit# Feedback welcomed!

Awesome!

override()

looks sweet and would simplify a lot of what I've been doing to add pants to StackStorm. Reducing the number of BUILD files is pretty sweet too (it's one of the things I've asked for on multiple occasions), though I have to cogitate about the implications (the awkward impact you pointed out) of doing that.

Idea inspired by the "target generation" idea at https://github.com/pantsbuild/pants/pull/12802. cc @happy-kitchen-89482, @witty-crayon-22786, and @fast-nail-55400 - appreciated to try to keep an open mind, I'm still thinking this through -- For Python, JavaScript, and Shell, we already are generating "file targets" by splitting up the "build targets" you define in BUILD files into one new target per

sources

. "Target generation" would be a generalization of that We lean into this -

python_tests

and

python_library

are split into targets that give metadata for a single file and "macros" that can generate those for you. (Strawman names ahead) The macro, e.g.

python_source_files

, becomes a blueprint for how to generate all those

python_source

targets. Thus, you can easily set default metadata for all the targets, but also set overrides

python_source_files(
    # Generate a target for each file.
    sources=["**/*.py"],
    # Metadata that applies to all files.
    tags=["my_tag"],
    # Overrides for specific files.
    overrides={
        ["foo.py"]: {"dependencies": ["//:resources"]},
     }
)

This is rather than the

override()

mechanism, which @witty-crayon-22786 pointed out is a new concept and not very unified. This cleans up the conceptual space: targets are metadata for atomic entities consumed in builds: a Python source file you can import and lint, a 3rdparty requirement, a PEX binary you want to build, a Go package (directory). It's atomic, the build happens at this level Then we also have macros like

python_requirements

and

python_source_files

that generate those atomic targets

I generally like the shape of the proposal, FWIW 🙂

Thanks, Daniel! Now ready for review: https://docs.google.com/document/d/1HpJn2jTWf5sKob6zhe4SqHZ7KWBlX4a6OJOwnuw-IHo/edit# Thanks Stu for talking this through yesterday! The proposal is more focused and concrete now

Looks good to me!