Hello, I am starting to wonder if I have some sort of misconfiguration in my setup, because even the simplest command takes a very long time.

time pants run //helpers/utils:utils
Usage: utils.pex [OPTIONS] COMMAND [ARGS]...

  Utility commands for working with Pants build system.

Options:
  --help  Show this message and exit.

Commands:
  env    Generate PYTHONPATH environment variables from Pants roots.
  list   List targets in the repository.
  roots  Show the pants build roots.

real    0m9.211s
user    0m5.290s
sys     0m1.500s

Hi all, got another question 🙂 I want to use pants to build a docker image with apko. I can get everything done locally, but not sure how to translate it into a pants BUILD file... I run the following commands: •

docker run --rm -v ${PWD}:/work -w /work <http://cgr.dev/chainguard/apko|cgr.dev/chainguard/apko> build image.yaml image:test test.tar.

•

docker load < test.tar

And then I can run the image.

👖 Pants pre-release testing 👖 Hey everyone! I'm aiming to cut Pants 2.26.0 later this week. Now is your chance to test it and identify any issues that we should fix before release, to make your upgrade path easier. Release notes: https://github.com/pantsbuild/pants/blob/529581f7cc59afbd08204c1196820b9266c37c9c/docs/notes/2.26.x.md When you have a moment, please validate it on any Pants-using codebases you have access to: 1. Edit

pants.toml

to say

pants_version = "2.26.0rc0"

2. Run your favourite commands like

pants lint ::

and/or run it through your CI 3. Let me know how it goes! If it works, or if there's issues/questions. By testing in advance, you help the Pants project and help yourself too: the sooner we catch issues, the better. Thank you! (If you have more time, please read over the release notes and test any features that catch your eye.)

Hi, I have a use case where I would like to create an "uberzip" of a subset of zip files generated and stored in dist/, what would be an elegant way of doing this?

We're using docker environments for integration tests running on Github Workflows. This is pretty nice, because we can do things like set up the database and other systems the way the integration tests expects. However, we can never test anything relying on our cloud provider because we can't put the keys in the dockerfile (with

docker run -v

) because there's just no way to customize docker running for environments. This is somewhat related to https://github.com/pantsbuild/pants/issues/18577, but in this case, we need to customize the docker run args, not the environment variable passed to the docker run command. My question is: is my understanding of the limitations correct? Am I missing some other way to do what we want? And if my understanding is correct, and there is no other way, should I open up a feature request for this?

vLLM, pex dependency resolution discrepancy. Possibly a bug in Pex or Pants version resolution? Hello team, I have added

vLLM

to my project and did a

pants generate-lockfiles

it successfully resolves the dependency and generate lock files but wen I run the test

pants test ::

I get:

stderr:
Failed to resolve requirements from PEX environment @ /private/var/folders/ng/pwvk62kx1qjfrw51wg4_bbtr0000gp/T/pants-sandbox-wZAf5t/requirements.pex.
Needed cp311-cp311-macosx_15_0_arm64 compatible dependencies for:
 1: datasets
    Required by:
      vllm 0.8.5
    But this pex had no ProjectName(raw='datasets', validated=False, normalized='datasets') distributions.

While in the lock file, I can see the architecture:

datasets-3.5.0-py3-none-any.whl

. How come

generate-lockfiles

is successful on getting the

whl

info but not

pants test

/ pex? Is there away to get around this issue? Thank you! 🙏

Does anyone have any thoughts/guidelines on converting a java gradle build to pants? I have some OSS code that I want to bring in repo and am not super excited to learn or maintain gradle as well as pants

oh man. Unpicking a project from "eh, it all uses 3.9" to "the pants-plugins use 3.11, the target runtime uses 3.10, and the 3.11 plugins generate 3.10 code for the target runtime, but anything else can be whatever" is uh... 'fun'

Hi folks. I've got one (maybe?) final question about using

pants package

. I'm building Python PEX apps, but for one of our target systems I need to use a custom wheel (I think because the OpenSSL version on the system is really frickin' ancient but that's by-the-by). I've set up a wheels directory and added this to my pants.toml:

[python-repos]
find_links = ['file://%(buildroot)s/wheels']
path_mappings = ['WHEELS_DIR|%(buildroot)s/wheels']

Which all works perfectly fine when I use

pants package

on my Mac. But when it runs on GitHub actions (Ubuntu), it seems to create a package without using the custom wheel I've supplied. I'm guessing the reason is that because Pants detects it's running on Linux, it thinks "aha, I can compile this myself, no need for that wheel file". Can I somehow force Pants to prefer my supplied wheel rather than compiling its own?

Actually disregard this for now - it isn't the right wheel. I've messed things up somewhere along the line. Back to the drawing board

What's the easiest way to debug a slow generate-lockfiles? Any way to get the verbose flag passed to pip so I could see where the dependency resolver is going haywire?

So hi again. I've found a solution for my wheel distribution issue but it is, to put it generously, a pretty ugly hack. 😛 I was wondering if there was a way to force a PEX distribution to bundle a dependency as source rather than a wheel? I had a look at

resolves_to_no_binary

but that doesn't seem to do what I want, which is for the dependency to be compiled on the prod system at runtime, rather than being pre-built

Hello, pantsbuild friends! We are wanting to compare implicit vs explicit field presence in some of our protobuf definitions. In order to do so we need to pass the parameter

--experimental_allow_proto3_optional

to protoc when pants build the *_pb2 files. Looking at the porotbuf_spource and protobuf_sources targets does not reveal any properties for specifying additional protoc parameters. Is this accurate or did I miss it?

Hi! I have a peculiar problem when building Docker images with Pants, locally. When building an image, Docker wants to pull the base image, so

load metadata <image name>

appears in the logs. However, it hangs forever, there are no warnings or network activity during this. When I pull the base image manually, the build works fine. I doubt it's a network-related problem because we pull various dependencies during the build, and it works fine. Building with Docker directly also works fine. Any idea what's wrong here? I browsed Slack and all threads that contain a mention of

load metadata

show an error, while in my case there's no error, it just keeps hanging. CC @clean-policeman-96974

We (Nativelink) are currently focused on improving our Pants integration over the next few weeks. If there is anyone here who would like to take a free spin of our remote execution and remote caching system at @ app.nativelink.com, please let me know. I'm also a personal sponsor of Pants (for now) and a corporate sponsor of Pants. Our system offers a basic build dashboard, with more features coming very soon, and it also offers a self-service remote execution UI where you can specify your container image and your cluster characteristics to get started if you want. I'd love to get feedback on how I can support the community more. It's such a great project.

Hey guys, I'm having an issue here with trying to test the CI pieces locally. To be specific, here's what I see:

pants \
 --changed-since=origin/main \
 tailor --check \
 update-build-files --check \
 lint

18:25:47.80 [INFO] Initializing scheduler...
18:25:47.82 [INFO] Initializing Nailgun pool for 24 processes...
18:25:50.15 [INFO] Scheduler initialized.
18:25:51.94 [ERROR] 1 Exception encountered:

Engine traceback:
 in Update all BUILD files

ProcessExecutionFailure: Process 'Find interpreter for constraints: CPython<4,>=3.7' failed with exit code 1.
stdout:

stderr:
No supported version of Pip is compatible with the given targets:
cp312-cp312-macosx_14_0_arm64 interpreter at /opt/miniconda3/envs/greenfield/bin/python3.12
cp313-cp313-macosx_14_0_arm64 interpreter at /opt/homebrew/Cellar/python@3.13/3.13.1/Frameworks/Python.framework/Versions/3.13/bin/python3.13
cp39-cp39-macosx_14_0_arm64 interpreter at /Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.9/bin/python3.9

Use `--keep-sandboxes=on_failure` to preserve the process chroot for inspection.

I'm currently running things in version

2.22.0

👖🚢 We've recently released Pants 2.26.0! https://www.pantsbuild.org/blog/2025/05/05/pants-2-26

Hello 🙂 Do unmatched globs cause any changes to pants performance?

Hi guys, I'm having trouble with building docker images. I want to build image based on env variable if available, else using the platform of the local os. A macro I registered so I can use it in build file:

def get_docker_platform():
    env_platform = os.getenv("DOCKER_PLATFORM")
    if env_platform:
        return env_platform
    arch = platform.machine()
    if arch == "x86_64":
        return "linux/amd64"
    elif arch in ["aarch64", "arm64"]:
        return "linux/aarch64"
    else:
        raise ValueError(f"Unsupported architecture: {arch}")

This function is working when no env variable is set, but when I try to set the env variable in my terminal it's ignored. do you have any idea how I could fix it?

how to unit-test a macro? I just want to ensure that for given inputs, it configures certain targets with specific values. I tried patching things like

files

or

docker_image

, but because no imports are allowed in the macro files, patching doesn't really work. I'd expect there are some utils that let us verify if given target functions were called

Hi all! Does pex respect the environment variable PYTHONSTARTUP? I want to use it to preload Sentry during execution

is there a way to continuously stream logs from Docker builds? all I got so far is

[docker]
build_verbose = true

but it prints the logs from Docker only after the command concludes. All we see for several minutes is e.g.:

14:17:25.02 [INFO] Starting: Building docker image <image name>

pants zsh completion troubleshooting ❓ I recently tried to setup

zsh

completions with

pants complete

and it doesn't seem to have made any difference. I'm wondering if anyone else noticed this? Or am I doing something wrong? More specifically, if I type

pants

in the repo root and hit tab, it only suggests the local files and folders to autocomplete. If I type something like

pant fm

or

pants li

and hit tab, it does not auto-complete the goal names

I just upgraded to 2.26.0 (from 2.24.1) and started seeing this error. I'm curious if anyone knows what the hell is causing this. Seems unrelated to pants, but I also don't know why upgrading pants would start this. Oh, and I also updated pex-cli from v2.20.2 to v2.32.4. > No pre-built wheel was available for pydevd-pycharm 243.22562.220. > > Successfully built the wheel pydevd_pycharm-243.22562.220-cp311-cp311-linux_x86_64.whl from the sdist pydevd_pycharm-243.22562.220.tar.gz but it is not compatible with the requested foreign target complete platform cp39-cp39-manylinux_2_36_x86_64. > > You'll need to build a wheel from pydevd_pycharm-243.22562.220.tar.gz on the foreign target platform and make it available to Pex via a

--find-links

repo or a custom

--index

.

Is it possible to build a pex that includes an sdist for one package instead of a wheel? The package I'm fighting with is

python-ldap

. The wheel ends up with the

linux_x86_64

platform tag (not with

manylinux*

because it links against

libldap

which is not one of the allowed libs for

manylinux*

. For

python-ldap

that is problematic because every distro and distro version seems to have a different version of

libldap

, so I can't reuse the pex anywhere except on the distro version I used to build it. So, it would be great if I could create a pex that includes an sdist instead of a wheel whenever the platform tag is too generic. That would require pex to build the wheel when the pex is first used instead of when building the pex. Is that possible? More details in 🧵.

Hi folks. When I run

pants lint ::

it throws a bunch of warnings, all right. However, when I re-run it, I suppose the warnings aren't shown anymore because of caching. However, it would be good if the output were shown, regardless of whether it is cached. That makes it easier to resolve warnings. Or is there another trick to show warning caching regardless?

Hi folks, reminder that at 1 PM PST today (Monday, May 12th) we’ll be having our monthly Pants developer meetup, as a huddle on the #C0D7TNJHL channel here in Slack. This is where we discuss the development of Pants itself, and is an opportunity to learn about what the maintainers are working on, and get involved in the future direction of the project. All are welcome, even just to lurk.

Happy call-by-name week to all who celebrate…

We build

.pex

binaries with pants, and I noticed there are options to

pex_binary

targets that lets you include or exclude sources and dependencies. I'm wondering if there's a smooth way to reduce packaging time in those cases where the dependencies haven't changed. For instance, we have quite a few binaries that package

torch

, which takes a cool 800MB and a handful of minutes to package, and it adds up to a lot of unnecessary time and resources. Is there a nice way to incrementally build the pex, or something else? I'm open to trying out the different

layout

options too. Right now we just build them with mostly default options to

pex_binary

.

When I check out a different branch that has e.g. a different plugin configuration, the pantsd server does not seem to restart and I see errors like

21:00:00.00 [ERROR] Invalid table name [new-subsystem-config] in pants.toml
21:00:00.00 [ERROR] Invalid config entries detected. See log for details on which entries to update or remove.

Similarly, when my checkout removes targets in BUILD files, the server doesn't seem to notice and I get warnings like "no matching files for glob '...' in 'old_target'".