https://pantsbuild.org/ logo
#general
Title
# general
h

hundreds-father-404

09/07/2021, 3:30 PM
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!
💯 1
1
👍 1
p

proud-dentist-22844

09/07/2021, 3:35 PM
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.
❤️ 1
h

hundreds-father-404

09/10/2021, 6:44 AM
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
Copy code
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
👍 2
This could possibly be disruptive for backwards compatibility, e.g. it may imply we drop the notion of "file addresses" and go back to one single type of address. As Benjy often reminds us, I'm trying to keep an open mind to what the ideal design is. Then we can finesse backwards compatibility
I think this idea has enough merit to continue fleshing it out. New design doc incoming :)
👍 1
Some details still need to be worked out, but main idea is ready for feedback: https://docs.google.com/document/d/1HpJn2jTWf5sKob6zhe4SqHZ7KWBlX4a6OJOwnuw-IHo/edit?usp=sharing cc @witty-crayon-22786 @happy-kitchen-89482
a

average-vr-56795

09/11/2021, 9:16 AM
I generally like the shape of the proposal, FWIW 🙂
h

hundreds-father-404

09/11/2021, 6:45 PM
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
w

witty-crayon-22786

09/12/2021, 1:37 AM
Looks good to me!
❤️ 1
6 Views