Open asherf opened 2 years ago
Currently, one role of targets is to explicitly opt into what Pants should operate on. But this isn't a compelling motivation - we can switch into an opt-out model. That's how ./pants tailor
works with its [tailor].ignore_*
options, and I think it works well.
I think the way we'll eventually "accomplish" this is through the "recursive" target generators @Eric-Arellano has been getting is nearer to.
So you'd just have a root BUILD
with python_sources(recurse=True)
(or whatever). We haven't decided overrides, but that's the gist.
Possibly -- for that to make sense, we might need support for a subdirectory BUILD file overriding a parent. Which imo is somewhat controversial and needs design. I'm not committed to "recursive target generators" or anything, but do indeed want to give us options.
Another approach discussed w/ several users in Slack is first-class support for BUILD file management, e.g. Buildozer. It would help w/ how annoying it is to update metadata for several places. It would not help, though, with the ugly aesthetics of mostly empty files.
IMO, we should close this one in favor of #13767, and add any keywords needed over there.
I think it might depend on which problem(s) we are prioritizing solving:
While related, https://github.com/pantsbuild/pants/issues/13767 seems more focused on the first problem of changing metadata for many files. In such that—a totally valid solution for https://github.com/pantsbuild/pants/issues/13767 is to lean into something like Buildozer—but that is not a valid solution for this issue.
I find that there are a lot of BUILD files contain just boilerplate:
or
or
Pants should be able to infer those so we don't actually need to have those on the file system and in source control.