Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

The gist of it is that there's a `tag` task which applies patterned rules from pants.ini to the tags of the all the targets in the graph

Then there's a `validate` task which checks all of the tags and dependencies edges against possible violations

And some tasks are manually annotated in the BUILD file using regular `tags = ...`

Okay, I'll see what I can do to get it into contrib, at the very least in the form of a CR

But this week I am slammed with fixit week and busily paying off high interest code debt

we've begun using tags more, and we'd like to ban test targets having dependees, etc

Spoiler alert: I wrote buildgen for python, and that is _definitely_ going upstream

<@U051221NF>: re: the language point on `src/jvm`: that would be handled by ignoring a directory after the `src` pattern

```Configuring explicit languages here (rather than just matching anything with a source-root-parent followed by one ignored directory) adds a lot of complexity. That's not to say I don't think we should do it... but I think it's important to justify it.

Are the advantages of an explicit language list sufficient to justify the complexity? Because without them you would go from 7 options to 2 (afaict).```

How would I know that src/jvm contains scala and java?

don't need to if you aren't enforcing target types

but if the goal is to figure out what language is under a particular root, i'd flip it

and reduce that to a dict that maps `'-jvm' -&gt; ['java, scala']`

<@U051221NF>: but that's forward looking, right? if you're not enforcing language locations, then actually determining what language is under a root isn't helpful yet

We're not doing anything with this distinction yet (will do a little bit with go, I think, once I migrate)

...but could be done in future by actually capturing the ignored directory

but either we have the lang functionality or we don't

<@U051221NF>: concrete proposal: capture the directory below the root, and assume it is a language.

and saying src/&lt;anything&gt; is a source root with language &lt;anything&gt; seems dangerous

<@U051221NF>: have a dict to allow for translating or mapping to other languages.

why is it? maybe it is, but i'm not seeing it

I'm not even 100% comfortable with the more explicit mappings. By which I mean, I'm not convinced they capture everyone's source root declaration needs. Hence the extra ways of specifying things.