Pants is a fast, scalable, user-friendly build system for codebases of all sizes.
Pants is an open-source project that is not owned or controlled by any one company or organization, and does incur some expenses. These expenses are managed by Pants Build, a non-profit that was established for this purpose. This non-profit's only source of revenue is sponsorship by individuals and companies that use Pants.
We offer formal sponsorship tiers for companies, as well as individual sponsorships via GitHub.
Thank you to Klayvio and Normal Computing for their Platinum tier support through throughout this release.
- macOS versions: Pants v2.25 is now built and tested on newer macOS versions: 13 (x86-64, previously 10.15) and macOS 14 (arm64, previously 11). The deprecation of the older versions were announced in Pants 2.23 and 2.24, and are driven by Apple's support schedule; they also help reduce cost for the volunteer-driven Pantsbuild organisation. Using Pants on older versions may or may not work.
- Fixed a longstanding bug in the processing of synthetic targets. This fix has the side-effect of requiring immutability and hashability of scalar values in BUILD files, which was always assumed but not enforced. This may cause BUILD file parsing errors, if you have custom field types involving custom mutable data structures. See (#21725) for more.
- Fixed bug where
pants --export-resolve=<resolve> --export-py-generated-sources-in-resolve=<resolve>fails (see #21659 for more info). - Fixed bug where an
archivetarget is unable to produce a ZIP file with no extension (see #21693 for more info). [subprocess-environment].env_varsandextra_env_vars(on many subsystems and targets) now supports a generalised glob syntax using Python fnmatch to construct patterns likeAWS_*,TF_*, andS2TESTS_*.
Pants now sends a user-agent header with every request to a remote store or a remote execution service,
even when other headers are configured. If necessary, the user may override the user agent by specifying
one in remote_store_headers or remote_execution_headers.
Pants now supports the {chroot} replacement marker in remote execution contexts. (With local and Docker execution, the {chroot} marker is replaced with the absolute path of the sandbox directory if it appears in program arguments or environment variables. Pants will do the same as well in remote execution contexts. This requires /bin/bash to be available on the remote execution server.)
The OpenDAL library powering the Github Actions cache backend has been updated, picking up some bug fixes for Github Enterprise Server instances using AWS S3 as backing storage for the Github Actions cache.
The "legacy" options system is removed in this release. All options parsing is now handled by the new, native parser.
The version of Python used by Pants itself has been updated to 3.11. To support this the Pants Launcher Binary known as scie-pants now has a minimum version of 0.12.2. To update to the latest launcher binary, either:
- Use the package manager you used to install Pants. For example, with Homebrew:
brew update && brew upgrade pantsbuild/tap/pants. - Use its built-in self-update functionality:
SCIE_BOOT=update pants.
That Pants itself happens to be partially writtin in Python has no bearing on the versions of Python that Pants can use to test and build your code.
Future versions of Pants will use a new parser for Dockerfiles, implemented in Rust. This parser is faster and does not require installing extra dependencies. To aid in this migration, please set the [dockerfile-parser].use_rust_parser option, to either (please let us know, if you find any issues with the new parser):
# Opt-in to the new parser now:
[dockerfile-parser]
use_rust_parser = true
# Or, continue using the old parser if you find issues with the new parser:
[dockerfile-parser]
use_rust_parser = falseStrict adherence to the schema of Docker registry configuration is now required. Previously we did ad-hoc coercion of some field values, so that, e.g., you could provide a "true"/"false" string as a boolean value. Now we require actual booleans.
Fixed an error which was caused when the same tool appeaed in both the --docker-tools and --docker-optional-tools options.
Strict adherence to the schema of Helm OCI registry configuration is now required. Previously we did ad-hoc coercion of some field values, so that, e.g., you could provide a "true"/"false" string as a boolean value. Now we require actual booleans.
The helm_infer.external_docker_images glob syntax has been generalized. In addition to *, you can now use Python fnmatch to construct patterns like quay.io/*.
Fixed a bug where linting with the Helm backend enabled could induce serialization errors with the workunit-logger.
The default "globs" for matching yaml in charts now matches more common structures.
Fixed an issue where pants run ... commands only worked if the package.json file was in the root directory.
The AWS Lambda backend now provides built-in complete platforms for the Python 3.13 runtime.
Constrained the transitive dependencies within the builtin lockfile for twine to work around a bug.
Several improvements to the Python Build Standalone backend (pants.backend.python.providers.experimental.python_build_standalone):
-
The backend now supports filtering PBS releases via their "release tag" via the new
--python-build-standalone-release-constraintsoption. THe PBS "known versions" database now contains metadata on all known PBS versions, and not just the latest PBS release tag per Python patchlevel. -
The backend will now infer metadata for a PBS release from a given URL if the URL conforms to the naming convention used by the PBS project. The inferred metadata is Python version, PBS release tag, and platform.
-
The
--python-build-standalone-known-python-versionsoption now accepts a three field format where each value isSHA256|FILE_SIZE|URL. All of the PBS release metadata will be parsed from the URL (which must use the naming convention used by the PBS project). (The existing five-field format is still accepted and will now allow the version and platform fields to be blank if that data can be inferred from the URL.) -
Metadata on PBS releases is current to PBS release 20250115.
Changed references to Python Build Standalone to not refer to the GitHub organization as described in Transferring Python Build Standalone Stewardship to Astral.
The default version of the Pex tool has been updated from 2.20.3 to 2.32.0. Among many improvements and bug fixes, this unlocks support for pip 24.3.1 and Pip 25.0.
The pants.backend.experimental.python.lint.ruff.check backend now supports including Ruff's output file as a report.
Fix a bug with the setup of the gRPC protobuf plugins where a go install invocation was prevented from accessing the Go module proxy during its build of those plugins, which caused those builds to fail.
A new experimental pants.backend.experimental.openapi.codegen.python backend
was added to support python codegen for OpenAPI documents.
The pants.backend.python.lint.black backend now uses version 24.8.0 by default, upgrading from 23.12.1. This comes with a new stable style (see release notes for 24.1.0 for details) which may result in extensive reformatting.
To override Pants' default version, use the install_from_resolve option and/or the interpreter_constraints option. The style changes may be extensive, so, to make upgrading to Pants 2.25 easier, we provide the old lockfile as built-in, for now (Pants will remove this in future, so you should switch to your own lockfile, and/or upgrade to the default Black 24, soon). To use this lockfile, and remain on Black 23, configure a resolve as follows:
# pants.toml
[python.resolves]
...
black = "resource://pants.backend.python.lint.black/black-23.12.lock"
[black]
install_from_resolve = "black"To take control of your Black version independent of Pants' default, configure a resolve similar to the following, and generate the lockfile with pants generate-lockfiles --resolve=your-resolve-name:
# pants.toml
[python.resolves]
...
your-resolve-name = "3rdparty/python/your-resolve-name.lock"
[black]
install_from_resolve = "your-resolve-name"# BUILD
python_requirement(name="black", resolve="your-resolve-name", requirements=["black>=23,<24"])Bugfix: fixed an issue with cache concurrency. This affected initialisation of modules without lockfiles (for example, with the check goal) and the generation of lockfiles. (#21805)
The previously deprecated [shell-setup].tailor option has now been removed. See [shell-setup].tailor_sources and [shell-setup].tailor_shunit2_tests to update.
The nFPM backend has a new plugin hook that allows plugins to inject field values that are used to generate nfpm config. To use this, a plugin needs to implement InjectNfpmPackageFieldsRequest:
from pants.backend.nfpm.fields.version import NfpmVersionField, NfpmVersionReleaseField
from pants.backend.nfpm.util_rules.inject_config import InjectedNfpmPackageFields, InjectNfpmPackageFieldsRequest
from pants.engine.internals.native_engine import Address, Field
from pants.engine.rules import rule
class MyCustomInjectFieldsRequest(InjectNfpmPackageFieldsRequest):
@classmethod
def is_applicable(cls, target) -> bool:
# this could check the target's address, packager, package_name field, etc.
return True
@rule
def inject_my_custom_fields(request: MyCustomInjectFieldsRequest) -> InjectedNfpmPackageFields:
# this could get the version from a file
version = "9.8.7-dev+git"
release = 6
fields: list[Field] = [
NfpmVersionField(version, request.target.address),
NfpmVersionReleaseField(release, request.target.address),
]
return InjectedNfpmPackageFields(fields, address=request.target.address)The dependency inference now considers .ts and .tsx file extensions.
The NodeJS subsystem now supports configuring additional tools that should be available in the NodeJS process execution. These tools can be configured via two options:
[nodejs].tools: Specify additional executables required by nodejs processes.[nodejs].optional_tools: Additional tools that may be needed but aren't required. Unliketools, the build won't fail if these aren't found. Useful for tools that only exist in some environments.
The paths to these tools will be included in the PATH used in the execution sandbox, so that they may be used by NodeJS processes during execution.
The version of Python used by Pants itself is now 3.11 (up from 3.9).
The oldest glibc version supported by the published Pants wheels is now 2.28. This should have no effect unless you are running on extremely old Linux distributions. See https://github.com/pypa/manylinux for background context on Python wheels and C libraries.
For the full changelog, see the individual GitHub Releases for this series: https://github.com/pantsbuild/pants/releases