To get started in a new repository, follow these steps, and then visit one of the language-specific overview pages.
Pants configuration lives in a file called
pants.toml in the root of the repo. This file uses the TOML format.
If you haven't yet, create a
[GLOBAL] pants_version = "$PANTS_VERSION"
$PANTS_VERSION is the version of Pants that you want to pin your repo to. When you'd like to upgrade Pants, edit
pants_version and the
./pants script will self-update on the next run.
Many languages organize code in a package hierarchy, so that the relative location of a source file on the filesystem corresponds to a logical package name. The directories that correspond to the roots of the language's package hierarchy are referred to as source roots. These are the filesystem locations from which import paths are computed.
For example, if your Python code lives under
import myorg.myproject.app will import the code in
In simple cases the root of the repository itself might be your only source root. But in many other cases the code is organized so that the source root is nested under some directory such as
To work correctly, Pants needs to know about the source roots in your repo. By default, given a source file path, Pants will treat the longest path prefix that ends in
src/py as its source root, falling back to the repo root itself if no such prefix is found.
If your project has a different structure, see Source roots for how to configure them, and for examples of different project structures you can use Pants with.
Golang projects can skip this step
Golang projects already use
go.modto indicate source roots.
Most Pants functionality is provided via pluggable backends, which are activated by adding to the
[GLOBAL].backend_packages option like this:
[GLOBAL] ... backend_packages = [ "pants.backend.go", "pants.backend.python", "pants.backend.python.lint.black", ]
See here for a list of available backends.
If you use Git, we recommend adding these lines to your top-level
# Pants workspace files /.pants.* /dist/ /.pids
FYI: Pants will ignore all files in your
pants_ignoreoption tells Pants which files to avoid looking at, but it additionally ignores all
.gitignored files by default. Occasionally, you will want to ignore something with Git, but still want Pants to work on the file. See Troubleshooting / common issues for how to do this.
BUILD files provide metadata about your code (the timeout of a test, any dependencies which cannot be inferred, etc). BUILD files are typically located in the same directory as the code they describe. Unlike many other systems, Pants BUILD files are usually very succinct, as most metadata is either inferred from static analysis, assumed from sensible defaults, or generated for you.
In general, you should create (and update) BUILD files by running
❯ ./pants tailor Created scripts/BUILD: - Add shell_sources target scripts Created src/py/project/BUILD: - Add python_sources target project - Add python_tests target tests Created src/go/BUILD: - Add go_mod target mod
Often, this will be all you need for Pants to work, thanks to sensible defaults and inference, like inferring your dependencies. Sometimes, though, you may need to or want to change certain fields, like setting a longer timeout on a test.
You may also need to add some targets that Pants cannot generate, like
To ignore false positives, set
[tailor].ignore_adding_targets. See tailor for more detail.
./pants tailor --checkin CI
We recommend running
./pants tailor --checkin your continuous integration so that you don't forget to add any targets and BUILD files (which might mean that tests aren't run or code isn't validated).
❯ ./pants tailor --check Would create scripts/BUILD: - Add shell_sources target scripts To fix `tailor` failures, run `./pants tailor`.
You're almost ready to go! Next up is visiting one of the language-specific overviews listed below.
Updated 3 months ago