#22743 bandit plugin can't use baseline file Issue created by vin Describe the bug I'm trying to use a baseline file with bandit, but it doesn't get included in the tool sandbox. I'm trying

[bandit]
install_from_resolve = "dev-tools"
config = "bandit.yaml"
args = ["--baseline", "bandit_baseline.json"]

I think I'd like

extra_files = ["bandit_baseline.json"]

but that option isn't supported in

[bandit]

Pants version 2.27 OS Linux Additional info pantsbuild/pants

#22752 regression in 2.29.0 when running `pants check` on a large repository Issue created by cburroughs When trying to run

pants check ::

in an internal Python repository I get 75 inscrutable mypy errors that were not present before. I use

mypy.install_from_resolve

so this is unrelated to the specific version of mypy. The exact errors seem to vary in a 'spooky' way based on which targets I

check

. From

git bisect

I've narrowed this down to da7cba5 (#22578). Prior to that change we would generate

__run.sh

scripts that look like:

-env -i MYPYPATH=$'my:source:roots' MYPY_FORCE_COLOR=1 MYPY_FORCE_TERMINAL_WIDTH=642092230765939 PEX_EXTRA_SYS_PATH=$'my:source_roots' TERM=ansi ./__mypy_runner.sh

But with that change the command instead has

PEX_EXTRA_SYS_PATH=''

. This is presumably due to:

diff --git a/src/python/pants/backend/python/typecheck/mypy/rules.py b/src/python/pants/backend/python/typecheck/mypy/rules.py
index 0c31d1f6d8..449bf0d47a 100644
--- a/src/python/pants/backend/python/typecheck/mypy/rules.py
+++ b/src/python/pants/backend/python/typecheck/mypy/rules.py
@@ -4,7 +4,6 @@
 from __future__ import annotations
 
 import dataclasses
-import itertools
 from collections.abc import Iterable
 from dataclasses import dataclass
 from hashlib import sha256
@@ -336,12 +335,9 @@ async def mypy_typecheck_partition(
         )
     )
 
-    all_used_source_roots = sorted(
-        set(itertools.chain(first_party_plugins.source_roots, closure_sources.source_roots))
-    )
     env = {
-        "PEX_EXTRA_SYS_PATH": ":".join(all_used_source_roots),
-        "MYPYPATH": ":".join(all_used_source_roots),
+        "PEX_EXTRA_SYS_PATH": ":".join(first_party_plugins.source_roots),
+        "MYPYPATH": ":".join(closure_sources.source_roots),
         # Always emit colors to improve cache hit rates, the results are post-processed to match the
         # global setting
         "MYPY_FORCE_COLOR": "1",

Possible Slack Thread Breadcrumb: https://pantsbuild.slack.com/archives/C046T6T9U/p1661627014305049 I am uncertain why

pantsbuild/pants

itself is unaffected. Perhaps generated protocal buffers are part of the puzzle? pantsbuild/pants

#22754 `pants test` doesn't run typescript tests. Issue created by yjabri Describe the bug TypeScript tests are not recognized by the

pants test

goal. I made https://github.com/yjabri/example-typescript. When running

pants test

nothing happens by default. However applying a slight patch, described below, and then running Pants from source seems to fix the issue. Pants version 2.28.0 (and likely all versions with TypeScript support) OS Linux (likely affects all platforms) Additional info I made the following changes to test a potential fix in `src/python/pants/backend/typescript/target_types.py`: https://github.com/yjabri/example-typescript/blob/main/pants-typescript-test-fix.patch. I'm not sure if this is the correct approach but it appears to work against https://github.com/yjabri/example-typescript. pantsbuild/pants

#22149 TypeScript: support checking Issue created by huonw Is your feature request related to a problem? Please describe. We have

typescript_source

and

tsx_test

targets (and so on), but the

check

goal doesn't find them, to run

tsc

. Describe the solution you'd like Running

pants check ::

with any typescript-y sources should run

tsc

on them. Describe alternatives you've considered None. Additional context N/A pantsbuild/pants

#22755 Audit Github Actions workflows Issue created by sureshjoshi We're around 4850 lines of yaml representing Pants workflows, which is generated by a 2000 line Python script. This wasn't easy to modify for some hacking I was trying to do, and it just seems like too much overall. It also puts us well above most projects I've worked on before - so it's probably worth seeing if we can trim some fat. pantsbuild/pants

#22759 Remove unused issue labels Issue created by sureshjoshi There are a bunch of unused (or not recently used) labels which are cluttering up issues. This ticket is to get rid of some of them, or merge others. Below are a list of tickets and approximate number of applied tickets: Suggestions: • "answered": 8 closed issues. A little redundant with “closed”. • "blocked": 1 open, 10 closed. Not consistently used. • "bsp": 6 open, 14 closed. Not consistently used. • "dependencies": Was previously used by dependabot - but not since 2023. Might be valuable for users flagging old deps. • "estimate": 11 open, 42 closed. Not used anymore. • "diagnostics/logging": Could be merged into "logging" • "remote": Maybe rename to something more specific? "remote-cache" i guess • ”security”: 2 tickets. • "stabilization": Useful if it's used. Is it used? • "triaged": 1 closed. More valuable as "needs-triage" and auto-applied to new tickets. • "user-registration": 37 closed. Last applied in 2023. Maybe useful if it's used pantsbuild/pants

#21109 Generate artifact attestations for Pants releases Issue created by benjyw See https://github.blog/changelog/2024-06-25-artifact-attestations-is-generally-available/ and https://docs.github.com/en/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds pantsbuild/pants

#19730 Introduce call-by-name syntax for `@rules` Issue created by stuhood (as motivated in #18905) Implementation: 1.

rule_graph

crate changes: • adjust the definition of

Get

(

DependencyKey

) for rule-graph solving to accept a fixed name/identifier for the rule to use, and some/all of its positional arguments • adjust graph solving to use the explicitly specified arguments to skip solving 2. syntax changes: • adjust the rule visitor (

AwaitableCollector

) to support extracting directly called

@rules

, in addition to the existing support for "rule helpers" • introduce an

implicitly(..)

builtin, which takes arguments similar to

Get(TypeName, ..)

• add support for positional arguments to

@rule

calls • implement support for call-by-name in

MultiGet

syntax • expose intrinsics as call-by-name (#20874) • determine new

@union

-usage syntax (or keep it type driven) 3. runtime changes: • adjust the

@rule

decorator such that when it has been called directly (i.e., not called with some secret-handshake), it trampolines back out to fill the additional positional arguments and to begin memoization • applies to both

async def

and

def

@rules

, since the act of memoizing can potentially mean blocking to wait for a result computed by another task • Use the

@rule

ids introduced in #19755 to drive

@rule

solving 4. deployment: • #20572 - add a

pants

-builtin goal which will execute a rewrite of one or more specified plugins or files from

await Get(TypeName, ..)

->

await rule_name(.., **implicitly(..))

• this requires rule-graph solving first (to select the

@rule

to use at each

Get

callsite), so the rewritten file must actually have been loaded • #21065 - migrate pants' code • Audit and change

@rule

names that are widely used in plugins/in-repo-backends in cases where they are not sufficiently descriptive. • Update docs for new syntax pantsbuild/pants

#16311 Document Prettier support Issue created by Eric-Arellano #15480 pantsbuild/pants

#17141 python typechecking: add support for pyright Issue created by smelc Would it be possible to add support for Microsoft's pyright typechecker for python files? It is available on pypi so it installs easily and has a straightforward CLI:

pyright py_files_to_check

. I have looked at the implementation of the backend for mypy but it doesn't seem so straightforward that I add the support on my own 🙂 Describe the solution you'd like Ideally, solving this issue would amount to making the following backend possible: backend_packages = [ "pants.backend.python.typecheck.pyright", ] Describe alternatives you've considered Using mypy, but it's not really an option since our existing monorepo uses

pyright

in its CI and in local development workflows. pantsbuild/pants

#21096 Mainline pants has a slow development cycle Issue created by sureshjoshi Pulled from the associated slack chat. Two problems I run into are: • As soon as I pull a new repo,

coursier

runs and starts downloading a bunch of stuff - even though I've never touched our java/jvm/scala/kotlin code • This is made worse, as I have network blocking on - and courier doesn't timeout - just tries to spin forever • Slow cycle time for negligible changes As an example of the 2nd. After fixing a typo in a function comment, and formatting, I spend 31 seconds waiting for that to finish. time pants fmt src/python/pants/goal/migrate_call_by_name* 0.58s user 0.06s system 2% cpu 30.932 total In some more egregious cases, I've waiting up to 60 seconds for a fmt/lint to run, and most of the time happens in the "scheduler" (handwaving everything before running the goal as "scheduler"). I narrowed the bulk of the time spent to commenting out

#"internal_plugins.test_lockfile_fixtures",

in the

pants.toml

- and then went further with removing the JVM entirely. The following diff brought my cycle time down to closer to 6-7 seconds (which I think can be even better). My integration tests also run about 1 second faster, for the 1 test I run. My git diff diff --git a/pants.toml b/pants.toml index 6b91bb1bbd..e52c003510 100644 --- a/pants.toml +++ b/pants.toml @@ -7,7 +7,6 @@ backend_packages.add = [ "pants.backend.build_files.fix.deprecations", "pants.backend.build_files.fmt.black", "pants.backend.python", - "pants.backend.experimental.python.packaging.pyoxidizer", "pants.backend.python.lint.autoflake", "pants.backend.python.lint.black", "pants.backend.python.lint.docformatter", @@ -19,28 +18,28 @@ backend_packages.add = [ "pants.backend.shell", "pants.backend.shell.lint.shellcheck", "pants.backend.shell.lint.shfmt", - "pants.backend.docker", - "pants.backend.docker.lint.hadolint", - "pants.backend.experimental.adhoc", - "pants.backend.experimental.go", - "pants.backend.experimental.java", - "pants.backend.experimental.java.lint.google_java_format", - "pants.backend.experimental.java.debug_goals", + #"pants.backend.docker", + #"pants.backend.docker.lint.hadolint", + #"pants.backend.experimental.adhoc", + #"pants.backend.experimental.go", + #"pants.backend.experimental.java", + #"pants.backend.experimental.java.lint.google_java_format", + #"pants.backend.experimental.java.debug_goals", "pants.backend.experimental.javascript", "pants.backend.experimental.javascript.lint.prettier", "pants.backend.experimental.python", - "pants.backend.experimental.python.packaging.pyoxidizer", - "pants.backend.experimental.scala", - "pants.backend.experimental.scala.lint.scalafmt", - "pants.backend.experimental.scala.lint.scalafix", - "pants.backend.experimental.scala.debug_goals", - "pants.backend.experimental.tools.workunit_logger", - "pants.backend.experimental.visibility", - "pants.backend.tools.preamble", - "pants.backend.tools.taplo", - "pants_explorer.server", - "internal_plugins.releases", - "internal_plugins.test_lockfile_fixtures", + #"pants.backend.experimental.python.packaging.pyoxidizer", + #"pants.backend.experimental.scala", + #"pants.backend.experimental.scala.lint.scalafmt", + #"pants.backend.experimental.scala.lint.scalafix", + #"pants.backend.experimental.scala.debug_goals", + #"pants.backend.experimental.tools.workunit_logger", + #"pants.backend.experimental.visibility", + #"pants.backend.tools.preamble", + #"pants.backend.tools.taplo", + #"pants_explorer.server", + #"internal_plugins.releases", + #"internal_plugins.test_lockfile_fixtures", ] plugins = [ "hdrhistogram", # For use with

--stats-log

. @@ -76,6 +75,12 @@ pants_ignore.add = [ build_ignore.add = [ # Disable Go targets by default so Pants developers do not need Go installed. "testprojects/src/go/**", + "testprojects/src/js/**", + "testprojects/src/jvm/**", + # Why is the docker backend under python? + "testprojects/src/python/docker/**", + "testprojects/src/ts/**", + "3rdparty/jvm/**", ] unmatched_build_file_globs = "error" @@ -203,8 +208,8 @@ requirements = ["//3rdparty/python:mypy"] [coverage-py] interpreter_constraints = ["==3.9.*"] -[preamble] -template_by_globs = "@build-support/preambles/config.yaml" +#[preamble] +#template_by_globs = "@build-support/preambles/config.yaml" [generate-lockfiles] diff = true @@ -213,30 +218,30 @@ diff = true args = ["--keep-runtime-typing", "--py38-plus"] -[jvm] -default_resolve = "jvm_testprojects" +#[jvm] +#default_resolve = "jvm_testprojects" -[jvm.resolves] +#[jvm.resolves] # A shared resolve for all testproject/example code. Because this is not shipped with Pants # binaries, it requires no isolation. -jvm_testprojects = "3rdparty/jvm/testprojects.lockfile" +#jvm_testprojects = "3rdparty/jvm/testprojects.lockfile" # A resolve for the java_parser, which is shipped with Pants, and invoked with its own isolated # classpath. Consequently, we isolate it to its own lockfile. # Note: The jvm_artifact targets in this resolve must be kept in sync with the requirements # in

generate_java_parser_lockfile_request

. -java_parser_dev = "src/python/pants/backend/java/dependency_inference/java_parser.lock" +#java_parser_dev = "src/python/pants/backend/java/dependency_inference/java_parser.lock" # Has the same isolation requirements as

java_parser

. # Note: The jvm_artifact targets in this resolve must be kept in sync with with the requirements # in

generate_scala_parser_lockfile_request

. -scala_parser_dev = "src/python/pants/backend/scala/dependency_inference/scala_parser.lock" -strip_jar_dev = "src/python/pants/jvm/strip_jar/strip_jar.lock" -jar_tool_dev = "src/python/pants/jvm/jar_tool/jar_tool.lock" +#scala_parser_dev = "src/python/pants/backend/scala/dependency_inference/scala_parser.lock" +#strip_jar_dev = "src/python/pants/jvm/strip_jar/strip_jar.lock" +#jar_tool_dev = "src/python/pants/jvm/jar_tool/jar_tool.lock" -[scala] -version_for_resolve = { "scala_parser_dev" = "2.13.8" } +#[scala] +#version_for_resolve = { "scala_parser_dev" = "2.13.8" } -[scalac] -args = ["-Yrangepos", "-Xlint:unused"] +#[scalac] +#args = ["-Yrangepos", "-Xlint:unused"] -[scala-infer] -force_add_siblings_as_dependencies = false +#[scala-infer] +#force_add_siblings_as_dependencies = false diff --git a/src/python/pants/backend/java/dependency_inference/BUILD b/src/python/pants/backend/java/dependency_inference/BUILD index d1d51d5dd1..f4d671b9e6 100644 --- a/src/python/pants/backend/java/dependency_inference/BUILD +++ b/src/python/pants/backend/java/dependency_inference/BUILD @@ -5,8 +5,8 @@ python_sources(dependencies=[":java_resources"]) resources(name="java_resources", sources=["*.java", "java_parser.lock"]) python_tests(name="tests", timeout=240) -# Targets for developing on the Java parser outside of engine rules. -java_sources( - name="java_parser", - resolve="java_parser_dev", -) +# # Targets for developing on the Java parser outside of engine rules. +# java_sources( +# name="java_parser", +# resolve="java_parser_dev", +# ) diff --git a/src/python/pants/backend/scala/dependency_inference/BUILD b/src/python/pants/backend/scala/dependency_inference/BUILD index 26b58ac2d7..2ed0e200c1 100644 --- a/src/python/pants/backend/scala/dependency_inference/BUILD +++ b/src/python/pants/backend/scala/dependency_inference/BUILD @@ -7,18 +7,18 @@ resources(name="scala_resources", sources=["*.scala", "scala_parser.lock"]) python_tests(name="tests", timeout=240) # Targets for developing on the Scala parser outside of engine rules. -scala_sources( - name="scala_parser", - resolve="scala_parser_dev", - # TODO: Allow the parser files to be formatted and linted. - skip_scalafmt=True, - skip_scalafix=True, -) +# scala_sources( +# name="scala_parser", +# resolve="scala_parser_dev", +# # TODO: Allow the parser files to be formatted and lin… pantsbuild/pants

#17352 NanoPB code generation Issue created by sureshjoshi This is more of a "note to self" to add code generation for NanoPB when the

cc

backend drops. I was lamenting having to write my own script for this yesterday, while having most of the tools we use already. pantsbuild/pants

#21100 Port `scie` plugin to mainline Issue created by sureshjoshi I've got a plugin that I've been using for about a year to package pexes into

scie

files using

science

. I didn't mainline it because John mentioned that eventually

pex

will gain this functionality natively, so it seemed silly to port this in. Today I realized, it's sillier to NOT port this in and then just eventually deprecate it in favour of the native tooling later. These are incredibly useful to me for non-docker deployments, and just making tooling easier on my machine (e.g. https://github.com/sureshjoshi/pantsible). https://github.com/sureshjoshi/pants-plugins/tree/main/pants-plugins/experimental/scie https://github.com/a-scie/jump https://github.com/a-scie/science pantsbuild/pants

#22769 Upgrade to Python 3.14 Issue created by sureshjoshi

pyo3

was was released yesterday with testing for 3.14.0, and there is a current PR for that support (#22768). There don't look to be too many deprecations, but there might be some work involving pkg_resources and some other older imports pantsbuild/pants

#22773 Set --confcutdir for python tests Issue created by oliverdain Describe the bug Per pytest-dev/pytest#11261, as of at least pytest 8.5 (though StackOverflow reports this started with 7.4 and I've seen it with 8.3) pytest no longer just looks up the directory tree looking for

conftest.py

files. Instead it either walks up the directory tree to the level of

--confcutdir

and no higher or, if that isn't set it walks up to the first "project marker file" (e.g. a

pytest.ini

,

pyproject.toml

, etc.) and stops there. If

--confcutdir

isn't set and no project marker file is found it doesn't walk up the directory tree at all (presumably for security as that might allow anybody to add code outside the project that would get executed). Currently Pants does not set

--confcutdir

so if users manually upgrade

pytest

their

conftest.py

files no longer get run. Pants version I'm using 2.28.0 but, AFAIK, all version are affected. OS Encountered on Linux but, per above, I think all versions are affected. Additional info there's a long Slack thread about this here: https://pantsbuild.slack.com/archives/C046T6T9U/p1760658668479529 At the end of that thread, @happy-kitchen-89482 suggested:

And if you feel like tackling it, it would be pretty straightforward, to update pytest_args in src/python/pants/backend/python/goals/pytest_runner.py

--confcutdir=./src should do it

pantsbuild/pants

#22779 pants check with Pyright fails with exit code 249 Issue created by mariap-pf Describe the bug When running

pants check

on a large number of Python targets, Pyright crashes right away with exit code 249. Example of output:

pants check ::
.
.
.
14:30:18.70 [INFO] Completed: Scheduling: Run Pyright on 1786 files.
14:30:18.70 [ERROR] Completed: Typecheck using Pyright - pyright - pyright failed (exit code 249).

✕ pyright failed.

Pants version 2.29.0 pyright version: 1.1.365 OS Ubuntu 22.04 Additional info This is blocking in CI where we use

--changed-since

to run checks only on affected targets, which prevents us from splitting the targets through other mechanisms (e.g. glob arguments). pantsbuild/pants

#22780 Look into replacing cargo audit with action Issue created by sureshjoshi https://github.com/rustsec/audit-check Debatable value - not sure about it yet. pantsbuild/pants

#21093 retry on downloading files server errors Issue created by cburroughs Is your feature request related to a problem? Please describe. We have recently seen a CI job fail along the lines of:

00:14:03.03 [ERROR] 1 Exception encountered:
Engine traceback:
  in `lint` goal
IntrinsicError: Server error (502) downloading file helm-unittest-linux-amd64-0.3.3.tgz from <https://github.com/helm-unittest/helm-unittest/releases/download/v0.3.3/helm-unittest-linux-amd64-0.3.3.tgz>

This is almost certainly a transient error. Describe the solution you'd like Some amount of retry/backoff for this class of errors. Describe alternatives you've considered Retry the entire CI job on any error. Besides using a lot more compute, I would prefer to avoid treats invocations of

pants

as flaky things that need retry-wrappers. Additional context

src/rust/engine/src/downloads.rs

has a variety of references to retries already, but I don't read Rust well enough to be clear on the current state. pantsbuild/pants

#20993 Run tests on MacOS ARM in CI Issue created by benjyw We currently run tests in CI on Linux ARM 64, Linux X86_64, and MacOS X86_64 (we build wheels for all 4 platforms, of course). However M1 adoption is now very far along, and Darwin X86_64 is, if anything, being phased out. So we should probably test on that platform. Related: we only run the full test suite on Linux X86_64, and run the "platform specific" test subset on the other two platforms, to save resources. We should probably run the full test suite for all platforms at least on main, if not for every PR. pantsbuild/pants

#22787 `pex` fails when a v2.29 dependency override is used Issue created by lowvoltage Describe the bug When a transitive dependency override is configured,

pants run

,

pants package

, etc. fail to run. Pants version 2.29.0 OS MacOS and Linux, or both Additional info Minimal setup to reproduce. We add

black

as a top-level dependency and override the version of its transitive dependency, `click`:

pants.toml

[GLOBAL]
pants_version = "2.29.0"
backend_packages = ["pants.backend.python"]

[python]
interpreter_constraints = ["==3.12.*"]
enable_resolves = true
default_resolve = "python-default"

[python.resolves]
python-default = "python-default.lockfile"

[python.resolves_to_overrides]
python-default = [
    "click==7.1",  # A transitive dependency of `black`: click>=8.0.0
]

main.py

import black  # Do not remove this import

if __name__ == '__main__':
    print('Hello, World!')

BUILD

python_sources()

python_requirement(
    name="requirements",
    requirements=["black"],
)

--- Generating the lockfile works fine, the correct overridden

click==7.1

is picked up:

❯ pants generate-lockfiles --resolve=python-default
17:54:30.67 [INFO] Initializing scheduler...
17:54:30.96 [INFO] Scheduler initialized.
17:54:34.10 [INFO] Completed: Scheduling: Find interpreter for constraints: CPython==3.12.*
17:54:39.34 [INFO] Completed: Generate lockfile for python-default
17:54:39.34 [INFO] Completed: Scheduling: Generate lockfile for python-default
17:54:39.36 [INFO] Wrote lockfile for the resolve `python-default` to python-default.lockfile

Lockfile diff: python-default.lockfile [python-default]

==                      Added dependencies                      ==

  black                          25.9.0
  click                          7.1
  mypy-extensions                1.1.0
  packaging                      25.0
  pathspec                       0.12.1
  platformdirs                   4.5.0
  pytokens                       0.2.0

However, trying to run the code fails:

❯ pants run main.py
17:55:50.74 [INFO] Completed: Scheduling: Building local_dists.pex
17:55:50.78 [INFO] Completed: Scheduling: Test binary /bin/bash.
17:55:52.75 [INFO] Completed: Building 1 requirement for .pex from the python-default.lockfile resolve: black
17:55:52.75 [INFO] Completed: Scheduling: Building 1 requirement for .pex from the python-default.lockfile resolve: black
17:55:52.75 [ERROR] 1 Exception encountered:

Engine traceback:
  in `run` goal

ProcessExecutionFailure: Process 'Building 1 requirement for .pex from the python-default.lockfile resolve: black' failed with exit code 1.
stdout:

stderr:
The --override option cannot be used when resolving against a lock file. Only overrides already present in the lock file will be applied.

Examining the command being run shows a

pex

call with

... --lock python-default.lockfile ... $'--override=click==7.1' ...

pantsbuild/pants

#22788 How to connect vscode debugger? New discussion created by stan-dot https://github.com/stan-dot/pants-python-tests/blob/main/src/python/fast_test/test_fast.py here's the test file pants promises support, here.

pants test --debug-adapter src/python/fast_test/test_fast.py

works ok, returns a localhost url. how to connect to it from vscode though to see the breakpoints correctly? pantsbuild/pants

#22789 Performance issue with very large set of ad-hoc tool calls Issue created by svenier Transferring from slack thread https://pantsbuild.slack.com/archives/C0D7TNJHL/p1761162382770779 Attempting to build a large graph of 163,375 targets results in pants memory growth and "unbounded" execution time. The source repository is at https://github.com/NVIDIA/Dependency-Patterns/tree/main/scaling and the command to run it is

pants run :go

. I was seeing this performance issue with 2.28.0 running on Linux accessing the files via NFS. Benjy was able to reproduce it running on macOS with local storage (not sure which pants version he was using). Some internal profiling shows lots of time spent waiting on the GIL. We have not done any stack inspections to see if, for example, transitive dependency traversal is doing redundant work for nodes deep in the graph. Our next experiment is going to be to try it against a BuildBarn remote execution farm to see if offloading it makes much difference. As a point of comparison Bazel is able to do the build in 9-10 minutes. pantsbuild/pants

#22790 Free Threaded Python Dependency Compatibility Issue created by cburroughs To use Free Threaded Python with no GIL every C abi dependency needs to support that https://docs.python.org/3/howto/free-threading-python.html#the-global-interpreter-lock-in-free-threaded-python. We need to: • Upgrade every dep to a version that supports with a free threaded version available. • Select (TBD how? Is there a regular marker ) the free threaded (

t

) version

user_reqs.lock

deps using C abi: • cryptography • psutil • pynacl pantsbuild/pants

#22795 Check support of Mypy's fixed format cache Issue created by sureshjoshi I don't know if this requires any changes to how Pants handles mypy caches. https://github.com/python/mypy/blob/master/CHANGELOG.md#fixedformat-cache-experimental pantsbuild/pants

#22797 Update default NodeJS and Package Managers Issue created by sureshjoshi We're still rocking Node 22 and the package managers have all had a major bump. pantsbuild/pants

#22086 Add a stalebot Issue created by sureshjoshi pantsbuild/pants

#22534 Update default pytest subsystem version to 8.x Issue created by zach-overflow ## Motivation • At the time of writing this, pytest's current stable release is at `8.4.1`, but Pants still defaults to

7.0.1

. • There are lots of feature additions and bug improvements between pytest

7.0.1

and

8.4.1

. At least in my case, many of the desired features translate to much broader pytest configuration control centralized in my codebase's

pyproject.toml

. • Moving to pytest 8.x would also mitigate a number of deprecation warnings that stem from older versions of pytest (see related issue thread here for one such example impacting us at the moment). ## Solution Description • Bump the default version of pytest to

8.x

. ## Alternatives Considered • Modify the pytest version in our project. Not totally opposed to this, but I wanted to see if there's any reason not to bump the version at the source. pantsbuild/pants

#22803 Dependabot `reviewers` has been removed in favour of code owners Issue created by sureshjoshi https://github.blog/changelog/2025-04-29-dependabot-reviewers-configuration-option-being-replaced-by-code-owners/ Should remove the reviewers from our Dependabot file, and (maybe) add a code owners. pantsbuild/pants

#22479 macos-13 Github Runners will stop working on November 14, 2025 Issue created by sureshjoshi https://github.blog/changelog/2025-07-11-upcoming-changes-to-macos-hosted-runners-macos-latest-migration-and-xcode-support-policy-updates/

macos-13 is closing down

The macOS 13 hosted runner image is closing down, following our N-1 OS support policy. This process will begin September 1, 2025, and the image will be fully retired on November 14, 2025. We recommend updating workflows to use macos-14 or macos-15.

pantsbuild/pants

#22807 Extract all JS/TS test code to resources Issue created by sureshjoshi It's very difficult to update as a mish-mash of some lockfiles, some inline lockfiles, some package.jsons, some inline package.json files I have 2 test failures after updating PNPM related to workspaces, but because I can't "just run" pnpm on the system to update or migrate, debugging these tasks is a chore. Ideally we could share the resources between those two backends too, but that's less important. The files themselves look like they were created and then inlined. A nice cherry on top would be a python/bash file that would auto-run all associated updates. pantsbuild/pants