Is there a way to set a default value for a target type in pants.toml? I am starting incremental adoption of mypy in our repo was hoping I could set

[mypy].skip=True

in pants.toml and then start setting

skip_mypy=False

on each target that is ready. When I do this it seems that the pants.toml config is a global setting and always wins, rather than the default value I was hoping for. The alternative is to use tags, which we did for tests and lint, but that requires more complex filtering logic on every run.

Unfortunately, the only way to do this at the moment is a macro. That has downsides like confusing your users because the macro will not show up in pants documentation https://www.pantsbuild.org/docs/macros Probably the best solution would behttps://github.com/pantsbuild/pants/issues/13767. We really want to do it, it is common feedback that it is far too clunky to set these skip fields. It is a bigger projects though We could also consider adding options to let you set the default, like you describe. It's relatively easy for us to implement, and would be pretty easy for you to knock out if you wanted to contribute. My only fear is if we would still want that mechanism if we had 13767? Wdyt?

This may seem tangential, but many of the use cases for 13767 could be handled with a tool that can do programatic edits to BUILD files. I have no knowledge of existing work in the python world for this but have a few such tools with go. Basically, the idea is that one could write a command that says "for all python_source's in this directory, set skip_mypy=True" and have that edit the BUILD files.

That is an interesting angle. See https://blog.pantsbuild.org/updating-pants-build-files-programmatically/ from @fresh-cat-90827

yes, thanks for mentioning this, Eric. That’s the approach I’ve taken and am happy with it —

buildozer

meets all the requirements I’ve had so far wrt to updating the

BUILD

files

cc @happy-kitchen-89482 @witty-crayon-22786 - this is an interesting point. Perhaps if we integrate Buildozer first class, hierarchical metadata is less necessary. I am still certainly open to the idea of hierarchical metadata. But in rewriting https://www.pantsbuild.org/docs/targets to talk about parameterization, it reminds me that targets have now become very complex already. I am nervous to add yet another mechanism around target and build files

oh you mean adding support for

buildozer

via a plugin, so it’s just another tool like

mypy

or

buf

?

yeah

thanks @hundreds-father-404 this is exactly the path I was hoping to take. would be great to have something like this baked into pants (to make it easier)

Interesting! How adequate of a solution do you think that blog is, particularly if it was made first class?

i mean, even if it weren't first class, it unblocks the work I am currently doing. making it first class would just make it easier for folks that are less experienced with the tools