Hi folks, reminder that the monthly Pants developer meeting is at 1 PM PST (in 40 minutes) as a huddle on this channel. All are welcome to join! Let me know if you have any agenda items.

message has been deleted

Hey @fierce-truck-19259 are you interested in discussing the nailgun issue?

I'm planning on adding some more metadata to the process execution workunit if anyone as any feedback https://github.com/pantsbuild/pants/issues/22203 This is to make inspecting the intermediate process outputs easier (as you fetch the digest from the remote cache if you know the fingerprint)

tl;dr Please vote on the best dates for CALL-BY-NAME WEEK! See thread for details.

Benjy Weinberger (Polly Sender: @happy-kitchen-89482) has a polly for you!

Release prep for 2.26.0rc0: https://github.com/pantsbuild/pants/pull/22214. Please rubber-stamp it if you have a second. The branch has been pretty stable (e.g. there hasn't been any issues filed against it) so potentially this is the first and only rc for 2.26.0. If there's no issues, I'm hoping to get that stable release out in ~1 week. (https://github.com/pantsbuild/pants/issues/22156)

Am I right in thinking that

run_rule_with_mocks

doesn’t work with call-by-name at the moment? At least that is what I’m seeing.

This is ready for review if anyone has a moment https://github.com/pantsbuild/pants/pull/22212

Ugh, this again, in CI:

psutil/_psutil_common.c:9:10: fatal error: Python.h: No such file or directory

Any chance someone could take a look at this one? https://github.com/pantsbuild/pants/pull/22218 It has very delimitating effects when hit and we think we've already found the solution there

I've taken the initiative to post https://github.com/pantsbuild/pants/pull/22227 with 2.27.0.dev3, because it's been quite a while since dev2 Please review 🙂 (Not meaning to step on MOTW toes, but I want https://github.com/pantsbuild/pants/pull/22160 to land in a relatively small dev release. I'm concerned that that might break things, and thus would prefer making narrowing down the cause to be easy.)

I believe we're good to go for 2.26.0 stable: https://github.com/pantsbuild/pants/pull/22226 (Please, no merging of cherry picks to the

2.26.x

branch until we either get that out or decide to wait.) Please review and/or let me know of any last minute concerns! 🙂

Anyone looked at batching gets from REAPI recently? I'm investigating a performance issue with fetching a large number of files in a directory (300k, node_modules) and I think batching might be able to help. I found https://github.com/pantsbuild/pants/issues/6990 and the linked stale/closed pr that I can use as a starting point. But open to your input here on how I should approach this. I'd also like to figure out how to confirm my hypothesis here prior to implementing it fully

Hey, I've got another docker environments related PR up. Looking for feedback before I fix the linting issues.

Based on the poll, call by name week shall be the week of… (drum roll) May 12 - May 18

Is there a preferred approach to profiling rust on osx? I see some old messages recommending Instruments but I'm not really familiar with using that. I found https://github.com/tikv/pprof-rs which looks interesting, would integrating something like this into pants be helpful to others? In theory this can ship with pants so users could profile using a cli flag and output a flame graph

hey folks, do we have a preferred way to activate debug/verbose in a tool when the

-ldebug

arg is passed? I can simply request

GlobalOptions

and then

if global_options.level > <http://LogLevel.INFO|LogLevel.INFO>:

, but is there a more approved way?

The 2.26.0 release cycle is mostly finished except: Reviews required for upgrades: • https://github.com/pantsbuild/example-golang/pull/23 • https://github.com/pantsbuild/example-javascript/pull/12 More assistance (i've not got time for debugging this in the near future): • The example-docker CI is broken for unrelated reasons: https://github.com/pantsbuild/example-docker/pull/25, first attempt at fixing in https://github.com/pantsbuild/example-docker/pull/26 Would someone like to cut the 2.27.x branch and switch main to be building towards 2.28.x?

I started looking into this issue because it would be very convenient for me if Pants could handle setting up

keyring

on its own. However, there's a bit of a thorny bootstrapping problem. My instinct, following the script I have that does this now, is to create a

keyring

subsystem, which is a

PythonToolBase

subsystem that can easily export a pex for

keyring

+ any additional dependencies, like

keyrings.google-artifactregistry-auth

. However, I believe the keyring pex needs to be added to to the

PATH

for pex_cli processes, which

python_tool_base.py

has a dependency on. Furthermore, there's also the issue of needing to call create a pex CLI process to create the keyring pex in the first place. Packaging keyring as an external tool is also problematic because it typically requires other Python dependencies to work with services like Google artifact registry. I also tried only importing the subsystem

if TYPE_CHECKING

but this doesn't work with the rule decorator. I was curious if anyone had any ideas or opinions on how to work around this.

Hi folks! I plan to cut the

2.27.x

release branch this weekend. So this is a last call for any outstanding PRs that you want to merge into

main

before I do so.

Unrelated: As mentioned above, next week is “Call-by-name Week”, a fixit week where we pull together to migrate pantsbuild/pants to use call-by-name instead of

Get

. This is an important step towards deprecating

Get

which in turn will allow us to simplify and speed up the solver (and therefore pantsd startup times). As it happens, the monthly Pants developer meeting is on Monday, so we will use that meeting to kick off the fixit week and discuss how each of us can help. Stay tuned for more info here!

Hey all, I wanted to get a quick pulse check before sending a PR to work around a performance issue we noticed while building a docker image. It seems it would be easy to have a subsystem option to flag on/off the suggested renames as a workaround. Would there be any opposition to a change like that for this case?

message has been deleted

[Call-by-name week] Here is the tracking spreadsheet: https://docs.google.com/spreadsheets/d/1Kngp00C2_KE_d1hk3NpqMLIrNeVfevRFAKMPqQJZ8_E/edit?usp=sharing

It currently contains all backends not marked as done in the tracking issue: https://github.com/pantsbuild/pants/issues/21065

There are probably a few backends that are not listed in either

But this is the bulk of the unmigrated codebase

early review sought: https://github.com/pantsbuild/pants/pull/22248 introduces a "library style" backend/plugin initialization API. I'd love some early feedback on the naming of classes and functions and general approach. (The API basically allows a plugin to be called in an imperative manner versus Pants calling various "framework style" methods like

target_types

and

rules

. Will benefit out-of-tree plugins which want a chance to run some logic consistently before registering things with the engine.)

Anyone familiar with why large-ish (10s of MB, so stored outside of lmdb) files might be slow when pulling from a remote cache? My first thought is either locking (insided sharedlmdb?) or queueing on the tokio threads (behind other work on the blocking threadpool) I've got ~10 files of this size that need to be pulled. A small cli app using reapi can pull them in 10s of milliseconds but pants is showing ~25 seconds. The flamegraph hasn't been too illuminating yet