reference:

Pants natively understands the semantics of a variety of build actions. These include "test", "lint", "fmt", "check", "package", "publish", "run", "repl" and more. It understands what these commands do and how that affects caching and concurrency

The basic idea is there is an API to add a goal. Say you want to add "doc" for generating documentation. ~All goals do their work by delegating. The way you do this is invent a type to represent the work, say

Documentation

in this case. The goal implementation then just asks Pants to produce

Documentation

for the files and targets supplied on the command line. Then, for each type of file or target that you know how to produce

Documentation

for, you write rules that do the real work, say a rule set that produces doc's via Sphinx for Python code. Those rules are written using the plugin API and they are also registered using the API.

But yeah, "natively" means "pre-packaged". You can extend these goals or create your own using the same mechanisms Pants does for those pre-packaged goals.

ditto

fmt

,

test

,

run

etc.

But you can also add your own goals that have nothing to do with these