#22176 Add support for dependency groups in pyproject.toml Issue created by b4rdos Is your feature request related to a problem? Please describe. Not exactly. I want to use pants with uv. They recently changed the way dev dependencies are defined and they are generated under

[dependency-groups]
dev = [...]

This is a recently accepted standard (see python docs) The existing

uv_requirements

target looks at

[tools.uv.dev-dependencies]

Describe the solution you'd like Allow for

python_requirements

to accept a group name as a reference to a

dependency-group

. Describe alternatives you've considered Manual copy of the dependency group into the old format - prone to user errors. Additional context Not any pantsbuild/pants

#22184 `experimental-destroy` for Terraform Issue created by d-m Is your feature request related to a problem? Please describe. It would be helpful if there was an

experimental-destroy

target to go along with

experimental-deploy

for the Terraform backend. Describe the solution you'd like A clear and concise description of what you want to happen.

pants experimental-destroy

would run

terraform destroy

pantsbuild/pants

#22189 Include `hdrhistogram` as a default dependency, for `[stats].log` Issue created by huonw Is your feature request related to a problem? Please describe. Pants has support for tracking "histograms" of metrics, for instance:

Summary of `local_store_read_blob_size` observation histogram:
    min: 1
    max: 4317183
    mean: 25249.341
    std dev: 158077.770
    total observations: 863
    sum: 21790181
    p25: 368
    p50: 1870
    p75: 8959
    p90: 44191
    p95: 110527
    p99: 337919

These are shown by the

[stats]

subsystem, when

[stats].log = true

, but require the

hdrhistogram

package to be installed. If

[stats].log = true

and that package isn't installed, Pants emits a warning:

`` Please run with

--plugins=hdrhistogram

if you would like histogram summaries to be shown at the end of the run, or permanently add

[GLOBAL].plugins = ['hdrhistogram']

. This will cause Pants to install the

hdrhistogram

dependency from PyPI. ``

The warning can be silenced either with

[GLOBAL].ignore_warnings

(if the user doesn't want to install the extra package), or by ... following the instructions: [GLOBAL] ... plugins = ['hdrhistogram'] ... [stats] log = true Describe the solution you'd like Include the

hdrhistogram

package unconditionally, and thus avoid needing to encourage users to install it. This introduces (pinned) versions of two new dependencies:

hdrhistogram

itself and its transitive dependency

pbr

, which total about ~1 MB uncompressed. Given we now package Pants as a PEX with all deps included, this doesn't seem like a major problem. There's always legimatinate concerns about introducing new dependencies / having "too many dependencies", but in this case

hdrhistogram

is already an optional dependency (although I think this relationship is not currently explicitly specified in metadata anywhere), we're not introducing new load. NB. as a side benefit, doing this reduces scope for supply chain attacks on Pants installs, because we won't be encouraging users to do unpinned installs of packages from PyPI (which is what

[GLOBAL].plugins = ['hdrhistogram']

means). See also #20166. Describe alternatives you've considered • Reimplementing the histogram tracking support to avoid

hdrhistogram

(e.g. as new code in the Pants repo, or shifting all logic to Rust code): this may be a sensible longer-term improvement, but doesn't seem like it should block the short-term improvement. Additional context Discussed in https://pantsbuild.slack.com/archives/C046T6T9U/p1744381091598199?thread_ts=1744347143.246149&cid=C046T6T9U pantsbuild/pants

#21955 AWS S3 download fails when using KMS encrypted objects Issue created by chris-smith-zocdoc Describe the bug When using KMS encrypted objects, S3 requires the use of sigv4 credential signing To reproduce, upload an object using a customer managed kms key

aws s3 cp foo.txt <s3://bucket/foo.txt> --sse aws:kms --sse-kms-key-id <key_id>

and try to download it using a file source

file(
    name="s3_file",
    source=http_source(
        url="<s3://bucket/foo.txt>",
        len=123,
        sha256="sha",
    )
)

run_shell_command(
    name="list_files",
    command="ls -lah {chroot}",
    execution_dependencies=[":s3_file"],
)

pants run :list_files

Produces an error like

IntrinsicError: Client error (400) downloading file foo.txt from <https://bucket.s3.amazonaws.com/foo.txt>

Pants version 2.24.1 OS Both Additional info toml to enable the backend

[GLOBAL]
pants_version = "2.24.1"
backend_packages = [
    "pants.backend.shell",
    "pants.backend.url_handlers.s3",
]
plugins = [
    'botocore==1.34.135'
]

pantsbuild/pants

#22195 Support Python interpreter pre-releases Issue created by huonw Is your feature request related to a problem? Please describe. Python does pre-releases of new major versions. It'd be great for Pants to make it easy to use one of these, e.g. to flush out bugs and/or experiment with new features. Currently, setting interpreter constraints to include a pre-release doesn't seem to work. For instance: I have

3.11.0a3

installed via pyenv but using this configuration [GLOBAL] pants_version = "2.27.0.dev2" backend_packages = ["pants.backend.python"] [python] interpreter_constraints = ["CPython==3.11.0a3"] Fails like:

11:11:43.99 [ERROR] 1 Exception encountered:

Engine traceback:
  in `run` goal

ProcessExecutionFailure: Process 'Find interpreter for constraints: CPython==3.11.0a3' failed with exit code 1.
stdout:

stderr:
Could not find a compatible interpreter.

Examined the following working interpreters:
1.)                                                           /Users/huon/.pyenv/versions/2.7.18/bin/python2.7 CPython==2.7.18
2.)                                                          /Users/huon/.pyenv/versions/3.10.1/bin/python3.10 CPython==3.10.1
3.)                                                          /Users/huon/.pyenv/versions/3.10.4/bin/python3.10 CPython==3.10.4
4.)                                                          /Users/huon/.pyenv/versions/3.11.0/bin/python3.11 CPython==3.11.0
5.)                                                          /Users/huon/.pyenv/versions/3.11.1/bin/python3.11 CPython==3.11.1
6.)                                                          /Users/huon/.pyenv/versions/3.12.0/bin/python3.12 CPython==3.12.0
7.)                                                           /Users/huon/.pyenv/versions/3.7.13/bin/python3.7 CPython==3.7.13
8.)                                                            /Users/huon/.pyenv/versions/3.8.7/bin/python3.8 CPython==3.8.7
9.)                                                            /Users/huon/.pyenv/versions/3.9.1/bin/python3.9 CPython==3.9.1
10.)                                                           /Users/huon/.pyenv/versions/3.9.10/bin/python3.9 CPython==3.9.10
11.)                                                           /Users/huon/.pyenv/versions/3.9.17/bin/python3.9 CPython==3.9.17
12.)                                                            /Users/huon/.pyenv/versions/3.9.7/bin/python3.9 CPython==3.9.7
13.)                                       /Users/huon/.local/share/mise/installs/python/3.10.14/bin/python3.10 CPython==3.10.14
14.)       /Users/huon/.cache/pants/pants_dev_deps/fe2d7dc6846a5cbc52083d73263bec9cf29e69e3.venv/bin/python3.11 CPython==3.11.9
15.)         /opt/homebrew/Cellar/python@3.12/3.12.7_1/Frameworks/Python.framework/Versions/3.12/bin/python3.12 CPython==3.12.7
16.)              /opt/homebrew/Cellar/python@3.8/3.8.19/Frameworks/Python.framework/Versions/3.8/bin/python3.8 CPython==3.8.19
17.)              /opt/homebrew/Cellar/python@3.9/3.9.20/Frameworks/Python.framework/Versions/3.9/bin/python3.9 CPython==3.9.20
18.)         /opt/homebrew/Cellar/python@3.13/3.13.0_1/Frameworks/Python.framework/Versions/3.13/bin/python3.13 CPython==3.13.0
19.)          /opt/homebrew/Cellar/python@3.10/3.10.15/Frameworks/Python.framework/Versions/3.10/bin/python3.10 CPython==3.10.15
20.) /Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.9/bin/python3.9 CPython==3.9.6

Describe the solution you'd like 1. Setting interpreter constraints that refer to pre-release versions should work if such a version is installed on the system 2. Python provider backends (like

pants.backend.python.providers.experimental.pyenv

and

pants.backend.python.providers.experimental.python_build_standalone

) should support installing pre-releases if they are published (see #22192 for prior work here) Describe alternatives you've considered N/A Additional context Testing Python pre-releases seems awkward in general; can Pants make it easier? pantsbuild/pants

#22200 `package` goal fails with `--changed-since=...` when including non UTF-8 files in `files` target Issue created by krylowicz Describe the bug I'm using files target to include text files that are used in unit tests. Some of these files intentionally contain non-UTF-8 characters, which are important for the test cases. However, when I run the pants package goal, it fails with an error related to character encoding. It appears only when using

--changed-since=...

, where the diff includes changes to non UTF-8 files. pants --print-stacktrace -ldebug --changed-since=a7b2003d --changed-dependents=transitive package 214454.56 [DEBUG] File handle limit is: 10000 214454.81 [INFO] Initializing Nailgun pool for 24 processes... 214454.81 [DEBUG] Using [cache::CommandRunner { inner: bounded::CommandRunner { inner: SwitchedCommandRunner { .. }, .. }, .. }, cache::CommandRunner { inner: bounded::CommandRunner { inner: SwitchedCommandRunner { .. }, .. }, .. }] for process execution. 214458.30 [DEBUG] Launching 1 roots (poll=false). 214458.34 [DEBUG] computed 1 nodes in 0.033700 seconds. there are 10 total nodes. 214458.34 [DEBUG] Launching 1 roots (poll=false). 214458.34 [DEBUG] computed 1 nodes in 0.000759 seconds. there are 14 total nodes. 214459.09 [DEBUG] File handle limit is: 10000 214459.14 [INFO] Initializing Nailgun pool for 24 processes... 214459.14 [DEBUG] Using [cache::CommandRunner { inner: bounded::CommandRunner { inner: SwitchedCommandRunner { .. }, .. }, .. }, cache::CommandRunner { inner: bounded::CommandRunner { inner: SwitchedCommandRunner { .. }, .. }, .. }] for process execution. 214503.04 [DEBUG] specs are: Specs(includes=RawSpecs(description_of_origin='CLI arguments', address_literals=(), file_literals=(), file_globs=(), dir_literals=(), dir_globs=(), recursive_globs=(), ancestor_globs=(), unmatched_glob_behavior=<GlobMatchErrorBehavior.error: 'error'>, filter_by_global_options=True, from_change_detection=False), ignores=RawSpecs(description_of_origin='CLI arguments', address_literals=(), file_literals=(), file_globs=(), dir_literals=(), dir_globs=(), recursive_globs=(), ancestor_globs=(), unmatched_glob_behavior=<GlobMatchErrorBehavior.error: 'error'>, filter_by_global_options=False, from_change_detection=False)) 214503.05 [DEBUG] changed_options are: ChangedOptions(since='a7b2003d', diffspec=None, dependents=<DependentsOption.TRANSITIVE: 'transitive'>) 214503.05 [DEBUG] Launching 1 roots (poll=false). 214503.09 [DEBUG] computed 1 nodes in 0.045949 seconds. there are 10 total nodes. 214503.09 [DEBUG] Launching 1 roots (poll=false). 214503.10 [DEBUG] Completed: acquire_command_runner_slot 214503.10 [DEBUG] Running Searching for

bash

on PATH=/usr/bin/bin/usr/local/bin:/opt/homebrew/bin under semaphore with concurrency id: 1, and concurrency: 1 214503.11 [DEBUG] /home/kkr/.cache/pants/lmdb_store/immutable/files -> /tmp hardlinkable: true 214503.11 [DEBUG] Completed: setup_sandbox 214503.12 [DEBUG] spawned local process as Some(695) for Process { argv: ["./find_binary.sh", "bash"], env: {"PATH": "/usr/bin/bin/usr/local/bin:/opt/homebrew/bin"}, working_directory: None, input_digests: InputDigests { complete: DirectoryDigest { digest: Digest { hash: Fingerprint<fc33a6ab65993fa57d52edbff44d8a8a89faa2ec0669950d238b481da5caf15c>, size_bytes: 91 }, tree: "Some(..)" }, nailgun: DirectoryDigest { digest: Digest { hash: Fingerprint<e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855>, size_bytes: 0 }, tree: "Some(..)" }, inputs: DirectoryDigest { digest: Digest { hash: Fingerprint<fc33a6ab65993fa57d52edbff44d8a8a89faa2ec0669950d238b481da5caf15c>, size_bytes: 91 }, tree: "Some(..)" }, immutable_inputs: {}, use_nailgun: {} }, output_files: {}, output_directories: {}, timeout: None, execution_slot_variable: None, concurrency_available: 0, description: "Searching for

bash

on PATH=/usr/bin/bin/usr/local/bin:/opt/homebrew/bin", level: Debug, append_only_caches: {}, jdk_home: None, cache_scope: PerRestartSuccessful, execution_environment: ProcessExecutionEnvironment { name: None, platform: Linux_x86_64, strategy: Local }, remote_cache_speculation_delay: 0ns, attempt: 0 } 214503.13 [DEBUG] Completed: Searching for

bash

on PATH=/usr/bin/bin/usr/local/bin:/opt/homebrew/bin 214503.13 [DEBUG] Completed: Scheduling: Searching for

bash

on PATH=/usr/bin/bin/usr/local/bin:/opt/homebrew/bin 214503.13 [DEBUG] Completed: acquire_command_runner_slot 214503.13 [DEBUG] Running Test binary /bin/bash. under semaphore with concurrency id: 2, and concurrency: 1 214503.13 [DEBUG] Completed: setup_sandbox 214503.14 [DEBUG] Completed: acquire_command_runner_slot 214503.14 [DEBUG] Running Test binary /usr/bin/bash. under semaphore with concurrency id: 3, and concurrency: 1 214503.14 [DEBUG] Completed: setup_sandbox 214503.14 [DEBUG] spawned local process as Some(696) for Process { argv: ["/bin/bash", "--version"], env: {}, working_directory: None, input_digests: InputDigests { complete: DirectoryDigest { digest: Digest { hash: Fingerprint<e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855>, size_bytes: 0 }, tree: "Some(..)" }, nailgun: DirectoryDigest { digest: Digest { hash: Fingerprint<e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855>, size_bytes: 0 }, tree: "Some(..)" }, inputs: DirectoryDigest { digest: Digest { hash: Fingerprint<e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855>, size_bytes: 0 }, tree: "Some(..)" }, immutable_inputs: {}, use_nailgun: {} }, output_files: {}, output_directories: {}, timeout: None, execution_slot_variable: None, concurrency_available: 0, description: "Test binary /bin/bash.", level: Debug, append_only_caches: {}, jdk_home: None, cache_scope: PerRestartAlways, execution_environment: ProcessExecutionEnvironment { name: None, platform: Linux_x86_64, strategy: Local }, remote_cache_speculation_delay: 0ns, attempt: 0 } 214503.15 [DEBUG] spawned local process as Some(697) for Process { argv: ["/usr/bin/bash", "--version"], env: {}, working_directory: None, input_digests: InputDigests { complete: DirectoryDigest { digest: Digest { hash: Fingerprint<e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855>, size_bytes: 0 }, tree: "Some(..)" }, nailgun: DirectoryDigest { digest: Digest { hash: Fingerprint<e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855>, size_bytes: 0 }, tree: "Some(..)" }, inputs: DirectoryDigest { digest: Digest { hash: Fingerprint<e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855>, size_bytes: 0 }, tree: "Some(..)" }, immutable_inputs: {}, use_nailgun: {} }, output_files: {}, output_directories: {}, timeout: None, execution_slot_variable: None, concurrency_available: 0, description: "Test binary /usr/bin/bash.", level: Debug, append_only_caches: {}, jdk_home: None, cache_scope: PerRestartAlways, execution_environment: ProcessExecutionEnvironment { name: None, platform: Linux_x86_64, strategy: Local }, remote_cache_speculation_delay: 0ns, attempt: 0 } 214503.15 [DEBUG] Completed: Test binary /usr/bin/bash. 214503.15 [DEBUG] Completed: Test binary /bin/bash. 214503.15 [DEBUG] Completed: Scheduling: Test binary /usr/bin/bash. 214503.15 [DEBUG] Completed: Scheduling: Test binary /bin/bash. 214503.15 [DEBUG] Completed: Finding the

bash

binary 214503.16 [DEBUG] Completed: acquire_command_runner_slot 214503.16 [DEBUG] Running Searching for

git

on PATH=/usr/bin/bin/usr/local/bin:/opt/homebrew/bin under semaphore with concurrency id: 4, and concurrency: 1 214503.16 [DEBUG] Completed: setup_sandbox 214503.17 [DEBUG] spawned local process as Some(698) for Process { argv: ["./find_binary.sh", "git"], env: {"PATH": "/usr/bin/bin/usr/local/bin:/opt/homebrew/bin"}, working_directory: None, input_digests: InputDigests { complete: DirectoryDigest { digest: Digest { hash: Fingerprint<74daa8164942a954dfa7b0e771e4a38e58b3dd98c3f2daffa9d54fcd98b6626a>, size_bytes: 91 }, tree: "Some(..)" }, nailgu… pantsbuild/pants

#22201 Support for PEP-751 lockfiles Issue created by ndellosa95 Is your feature request related to a problem? Please describe. PEP-751, a standardized lockfile format for Python, is accepted. While we need to wait for the tools Pants leverages to generate lockfiles to support it, we can use this ticket to track any necessary changes within Pants itself. Describe the solution you'd like

pants generate-lockfiles

generates a PEP-751 lockfile. I've opened a related ticket on the pex side for this work. Presumably Pants will just need to delegate to pex, which will delegate to pip, once this is implemented there. Describe alternatives you've considered Uv will support this as well at some point too. It would still be ideal to support uv as an alternative to pex in the future. pantsbuild/pants

#22203 Include digest in workunit metadata Issue created by chris-smith-zocdoc Is your feature request related to a problem? Please describe. One challenging scenario for us to debug is inspecting the results of intermediate process executions. This is especially true when dealing with remote (CI) runners. We have bazel-remote setup and a custom workunit logger but currently there are two pieces of critical missing metadata. 1. The output digest from process executions 2. The action cache digest prior to processes execution Describe the solution you'd like Both of these digests should be included in the workunit metadata so we can look them up in bazel-remote. Additional context I believe the output digest fingerprint can be added here in execute_process.rs I haven't looked up the action cache one yet, but think it should be added to the

check_action_cache

workunit pantsbuild/pants

#22208 Using `shell_command` with `terraform_deployment` New discussion created by d-m Hello, I am trying to use

shell_command

to create a Terraform workspace that can be used by a subsequent

terraform_deployment

target. The

BUILD

file looks like the following:

shell_command(
    command="terraform workspace new ${TF_WORKSPACE} || terraform workspace select ${TF_WORKSPACE}",
    tools=["terraform"],
    extra_env_vars=["TF_WORKSPACE"],
    log_output=True
)

terraform_deployment(
    dependencies=[
        ":shell_command",
        ...
    ],
)
...

However, when I run this with

TF_WORKSPACE="my-workspace" pants experimental-deploy --dry-run ::

the

shell_command

doesn't seem to run and goes right to the deployment where I get a "the currently selected workspace (my-workspace) does not exist" error. Any help would be appreciated. Thanks! pantsbuild/pants

#22209 Support for Terraform workspaces with Terraform backend Issue created by d-m Is your feature request related to a problem? Please describe. Terraform provided the ability to segment state for different deployments in workspaces that can be created or selected with

terraform workspace new <name>

and

terraform workspace select <name>

, respectively. Using these would be easier if the TerraformDeploymentTarget accepted a

workspace

parameter and this was used to create or select a workspace. Describe the solution you'd like A

workspace

parameter was set, possibly by environment variable, and used like so:

terraform_deployment(
    ...
    workspace="my-workspace",
    ...
)

Describe alternatives you've considered I've tried creating a

shell_command

(#22208) to create the workspace and set it as a dependency to a

terraform_deployment

but I couldn't get it to run. I've also tried using a

run_shell_command

target and running

pants run

. This worked if there was only one

run_shell_command

but didn't if there were multiple, for example a monorepo with multiple terraform projects. Additional context Terraform can sometimes create a new workspace automatically (hashicorp/terraform#21393 (comment), hashicorp/terraform#21393 (comment)), but it is not guaranteed for all backend providers and often returns this error:

Initializing the backend...

The currently selected workspace (my-workspace) does not exist.
  This is expected behavior when the selected workspace did not have an
  existing non-empty state. Please enter a number to select a workspace:
  ...

It is more consistent to run

terraform workspace new

to create it. pantsbuild/pants

#21982 stabilize `experimental_test_shell_command` as `test_shell_command` Issue created by tdyas Tasks to complete to stabilize

experimental_test_shell_command

as `test_shell_command`: • Support capturing outputs as test "extra outputs." • #21981 • #22002 • Support

runnable_dependencies

field. #22003 • Update documentation to be current. For example, reflect how

CHROOT

is not actually set during executions. pantsbuild/pants

#18209 `Container ... is not running` error if a docker environment container stops while pantsd is running Issue created by huonw Describe the bug If pants starts a particular docker environment, and that environment dies (e.g. the user restarts the docker daemon or kills the container), pantsd seems to jam up and emits errors about the container not running or not existing. Pantsd has to be killed and restarted to resolve the issue. Reproducer: https://gist.github.com/huonw/95a15c5cac3c5fcaf0aee3f8b63f8116 git clone https://gist.github.com/huonw/95a15c5cac3c5fcaf0aee3f8b63f8116 cd 95a15c5cac3c5fcaf0aee3f8b63f8116 ./run.sh

# run.sh
#!/bin/bash

pkill -f pantsd

pants version
#> 2.15.0rc4

echo "# $(date +%s)" > x.py
pants package :pex
#> ... Wrote dist/pex.pex

docker stop $(docker ps -aq)

echo "# $(date +%s)" > x.py
pants package :pex
#> ... Failed to create Docker execution in container: DockerResponseServerError { status_code: 409, message: "Container 3be6e437f53c48f195f699ea0193914c68632773765a4b6d9a1d6b8d78190d7e is not running" }

docker rm $(docker ps -aq)

echo "# $(date +%s)" > x.py
pants package :pex
#> ... Failed to create Docker execution in container: DockerResponseServerError { status_code: 404, message: "No such container: 3be6e437f53c48f195f699ea0193914c68632773765a4b6d9a1d6b8d78190d7e" }

Pants version 2.15.0rc4 OS macOS Additional info https://gist.github.com/huonw/95a15c5cac3c5fcaf0aee3f8b63f8116 pantsbuild/pants

Comment on #22208 Using `shell_command` with `terraform_deployment` Discussion answered by lilatomic 2 things are needed: 1. you need to collect the files output by the

shell_command

shell_command( name="tf_workspace", command="terraform workspace new ${TF_WORKSPACE} || terraform workspace select ${TF_WORKSPACE}", tools=["terraform"], extra_env_vars=["TF_WORKSPACE"], log_output=True, + output_files=[".terraform/environment"], + output_directories=["terraform.tfstate.d"], # maybe just for local state ) 1. you need #22202 which allows pulling in

resources

. This patch is targetting release in 2.27 pantsbuild/pants

#22219 support specific dependencies for node_build_script Issue created by kevin-oliveira-zocdoc Is your feature request related to a problem? Please describe. As of now, if I need certain dependencies during an execution of a

node_build_script

, I need to specify them as a dependency of the

package_json

target itself, which is not exactly good for caching purposes, as if any the dependencies changes, all

node_build_script

result caches would be invalidated. e.g. package_json( name="package_json", dependencies=[ "//:my_dep_target" ], scripts=[ node_build_script( entry_point="build", output_directories=["dist"], ), node_build_script( entry_point="some-other-script", output_directories=["foo"], ), ], ) Lets say

my_dep_target

is just necessary for the

build

script, it would still be included on the sandbox when running

some-other-script

, and if that target changes, the cache of

some-other-script

would be invalidated. Describe the solution you'd like I think we could have a

dependencies

field on the node_build_script where we could set specific dependencies for certain scripts. The above use case could be changed to something like: package_json( name="package_json", scripts=[ node_build_script( entry_point="build", output_directories=["dist"], dependencies=[ "//:my_dep_target" ], ), node_build_script( entry_point="some-other-script", output_directories=["foo"], ), ], ) pantsbuild/pants

#22220 support package/run "only" node scripts Issue created by kevin-oliveira-zocdoc Is your feature request related to a problem? Please describe. Right now theres no way to define a node script with a "run" only mode, as

node_build_script

also implements the

package

goal, so let say the CI pipeline runs something like

pants package ::

the defined

node_build_script

would be executed, e.g. package_json( name="package_json", scripts=[ node_build_script( entry_point="only-run", output_directories=["foo"], ), ], ) Describe the solution you'd like Maybe a

node_run_script

could be created where just the

run

goal is implemented? Also maybe theres no need to require

output_directories

or

output_files

on a

node_run_script

? The current

node_build_script

does require either: pants/src/python/pants/backend/javascript/package/rules.py Lines 138 to 150 in</pantsbuild/pants/commit/82b1bb82fd4b609856c2aeab7ebb929793d52427|82b1bb8> | def __post_init__(self) -> None: | | ----------------------------------------------------------------------- | | if not (self.output_directories or self.output_files): | | raise ValueError( | | softwrap( | | f""" | | Neither the {NodeBuildScriptOutputDirectoriesField.alias} nor the | | {NodeBuildScriptOutputFilesField.alias} field was provided. | | | | One of the fields have to be set, or else the

{NodeBuildScript.alias}

| | output will not be captured for further use in the build. | | """ | | ) | | ) | We have use cases where we wanna run a

yarn ...

command but the output is not necessary, just the exit code != 0 would be enough. pantsbuild/pants

#22221 remote cache: support transfer of compressed blobs Issue created by chris-smith-zocdoc Is your feature request related to a problem? Please describe. The REAPI has the ability to send zstd compressed blobs back to the client, without decompressing them on the server. This may be beneficial to reduce bytes sent over the network or offloading compression overhead to the pants client. Describe the solution you'd like If the remote cache supports this capability, the pants client should be able to send and receive zstd compressed blobs Additional context REAPI bazelbuild/remote-apis#168 Slack convo https://pantsbuild.slack.com/archives/C046T6T9U/p1745612691482359 pantsbuild/pants

#22224 Additional diagnostics about reason for pantsd restarts Issue created by huonw Is your feature request related to a problem? Please describe. Currently, the pantsd daemon will restart sometimes for non-obvious reasons. This can take a long time. It'd be nice if there was more diagnostics about why each restart happens, so that people can solve "obvious" issues and reduce spurious restarts. Currently, it'll just say something like the following, with no indication of which options changed:

12:25:06.88 [INFO] Initialization options changed: reinitializing scheduler...
...

Describe the solution you'd like At least one of: 1. When the scheduler needs to restart, the "reinitialising" message should summarise what's changed (e.g.

Initialization options (--pants-distdir, --level) changed: ...

) 2. Setting

--level=debug

should include all the details 3. The

pants.log

file should include all the details unconditionally I think we shouldn't just rely on (2) (

--level=debug

) because it can be hard to reproducer scheduler restarts, to be able to re-run with

--level=debug

, and, setting that setting itself requires a restart and thus might disturb observations. The code that decides when to restart and how to explain it is at: pants/src/python/pants/pantsd/pants_daemon_core.py Lines 134 to 164 in</pantsbuild/pants/commit/82b1bb82fd4b609856c2aeab7ebb929793d52427|82b1bb8> | scheduler_restart_explanation: str \| None = None | | ------------------------------------------------------------------------------------------- | | | | # Because these options are computed dynamically via side effects like reading from a file, | | # they need to be re-evaluated every run. We only reinitialize the scheduler if changes | | # were made, though. | | dynamic_remote_options, auth_plugin_result = DynamicRemoteOptions.from_options( | | options, | | env, | | self._prior_auth_plugin_result, | | remote_auth_plugin_func=build_config.remote_auth_plugin_func, | | ) | | remote_options_changed = ( | | self._prior_dynamic_remote_options is not None | | and dynamic_remote_options != self._prior_dynamic_remote_options | | ) | | if remote_options_changed: | | scheduler_restart_explanation = "Remote cache/execution options updated" | | | | # Compute the fingerprint of the bootstrap options. Note that unlike | | # PantsDaemonProcessManager (which fingerprints only

daemon=True

options), this | | # fingerprints all fingerprintable options in the bootstrap options, which are | | # all used to construct a Scheduler. | | options_fingerprint = OptionsFingerprinter.combined_options_fingerprint_for_scope( | | GLOBAL_SCOPE, | | options_bootstrapper.bootstrap_options, | | ) | | bootstrap_options_changed = ( | | self._fingerprint is not None and options_fingerprint != self._fingerprint | | ) | | if bootstrap_options_changed: | | scheduler_restart_explanation = "Initialization options changed" | I suspect the

self._fingerprint

string could store a (stable) JSON blob, rather than a hash, to be able to introspect the differences between old and new. Describe alternatives you've considered Making scheduler restarts so fast that it doesn't matter when it happens... this seems unobtainable in the short term. Additional context N/A pantsbuild/pants

#22225 How do you setup your IDE to recognise 3rdparty jvm dependencies? New discussion created by jackson3stack I'm using the example-jvm repo (https://github.com/pantsbuild/example-jvm) to understand how I can avoid dependencies not being inferred/picked up by IntelliJ IDEA. The following image is of the project opened in the IDE. The resolves aren't correct. [image](https://private-user-images.githubusercontent.com/31636668/439073951-5f3b2be7-7571-4b00-b8b7-653fee061247.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NDU5ODk2ODgsIm5iZiI6MTc0NTk4OTM4OCwicGF0aCI6Ii8zMTYzNjY2OC80MzkwNzM5NTEtNWYzYjJiZTctNzU3MS00YjAwLWI4YjctNjUzZmVlMDYxMjQ3LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTA0MzAlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwNDMwVDA1MDMwOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTU0MDg3MzA3ODFkY2Q1OTM3ZDgyMzQyZmIxZjgwMjg0ZjUzN2NmYWExM2RkMmFhY2Y5NzNiMDJmMTdmNmU4NDImWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.8l0Uqm3Kf5l_zv74VEpUzUVyv4m_kaKhCCVc5YDcEv8) I haven't changed any files. I assumed this would not be a problem. I also researched a lot on how jvm can be handled in the IDE, I've gone through all the

experimental-bsp

steps and bsp is working, syncing and compiling correctly but still the dependencies aren't being found. My bsp sync does not show the dependencies such as google's guava. [image](https://private-user-images.githubusercontent.com/31636668/439075153-f7f10cb8-e7c4-415d-a847-cab57acff37e.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NDU5ODk2ODgsIm5iZiI6MTc0NTk4OTM4OCwicGF0aCI6Ii8zMTYzNjY2OC80MzkwNzUxNTMtZjdmMTBjYjgtZTdjNC00MTVkLWE4NDctY2FiNTdhY2ZmMzdlLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNTA0MzAlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjUwNDMwVDA1MDMwOFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWI5ZTg2ZmRlYTMxOTI2NzI1NTNlZWViZGVjNjJlNDJkM2U2ZDYwMWM1ODNhNGNiMzAwNzc3ZjNhNGY0ZDFhZTgmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0In0.Iiwrkxervpd1rhd5cu5xVZz3zf-YhsV-MfLF3aV1iOA) How can I either use bsp to register all dependencies in the project or resolve them automatically? What's required? I can't find any documentation to solve this. pantsbuild/pants

#21048 Python provider not used for `pants package` of `pex_binary` target Issue created by kaos Describe the bug When using

pants.backend.python.providers.experimental.pyenv

test, lint and check works fine, but package fails. Pants version 2.21.0 OS Ubuntu Additional info

13:03:09  pants lint check test package ::
13:03:15  13:03:15.48 [INFO] waiting for pantsd to start...
13:03:18  13:03:17.78 [INFO] pantsd started
13:03:18  13:03:18.30 [INFO] Initializing scheduler...
13:03:24  13:03:24.02 [INFO] Scheduler initialized.
13:03:24  13:03:24.51 [INFO] Starting: Choose specific version for Python 3.9
13:03:24  13:03:24.68 [INFO] Completed: Choose specific version for Python 3.9
13:03:24  13:03:24.92 [INFO] Starting: Building isort.pex from <resource://pants.backend.python.lint.isort/isort.lock>
13:03:24  13:03:24.92 [INFO] Starting: Building black.pex from <resource://pants.backend.python.lint.black/black.lock>
13:03:25  13:03:24.97 [INFO] Starting: Building autoflake.pex from <resource://pants.backend.python.lint.autoflake/autoflake.lock>
13:03:25  13:03:24.97 [INFO] Starting: Building docformatter.pex from <resource://pants.backend.python.lint.docformatter/docformatter.lock>
13:03:25  13:03:24.97 [INFO] Starting: Building flake8.pex from <resource://pants.backend.python.lint.flake8/flake8.lock>
13:03:25  13:03:25.01 [INFO] Canceled: Building black.pex from <resource://pants.backend.python.lint.black/black.lock>
13:03:25  13:03:25.01 [INFO] Starting: Building black.pex from <resource://pants.backend.python.lint.black/black.lock>
13:03:25  13:03:25.01 [INFO] Canceled: Building black.pex from <resource://pants.backend.python.lint.black/black.lock>
13:03:25  13:03:25.01 [INFO] Starting: Building black.pex from <resource://pants.backend.python.lint.black/black.lock>
13:03:27  13:03:26.58 [INFO] Completed: Building isort.pex from <resource://pants.backend.python.lint.isort/isort.lock>
13:03:27  13:03:26.62 [INFO] Completed: Building flake8.pex from <resource://pants.backend.python.lint.flake8/flake8.lock>
13:03:27  13:03:26.63 [INFO] Completed: Building autoflake.pex from <resource://pants.backend.python.lint.autoflake/autoflake.lock>
13:03:27  13:03:26.67 [INFO] Completed: Building docformatter.pex from <resource://pants.backend.python.lint.docformatter/docformatter.lock>
13:03:27  13:03:26.85 [INFO] Completed: Building black.pex from <resource://pants.backend.python.lint.black/black.lock>
13:03:27  13:03:26.85 [INFO] Completed: Format with docformatter - docformatter made no changes.
13:03:27  13:03:26.86 [INFO] Completed: Format with isort - isort made no changes.
13:03:27  13:03:26.93 [INFO] Completed: Fix with Autoflake - autoflake made no changes.
13:03:27  13:03:26.97 [INFO] Completed: Lint with Flake8 - flake8 succeeded.
13:03:27  Partition: ['CPython==3.9.*']
13:03:27  
13:03:27  
13:03:27  13:03:27.26 [INFO] Completed: Format with Black - black made no changes.
13:03:27  
13:03:27  ✓ autoflake succeeded.
13:03:27  ✓ black succeeded.
13:03:27  ✓ docformatter succeeded.
13:03:27  ✓ flake8 succeeded.
13:03:27  ✓ isort succeeded.
13:03:27  13:03:27.51 [INFO] Starting: Building mypy.pex from <resource://pants.backend.python.typecheck.mypy/mypy.lock>
13:03:27  13:03:27.57 [INFO] Starting: Building 4 requirements for requirements.pex from the 3rdparty/default.lock resolve: click, pantsbuild.pants.testutil==2.21.0, pantsbuild.pants==2.21.0, pytest
13:03:29  13:03:29.32 [INFO] Completed: Building mypy.pex from <resource://pants.backend.python.typecheck.mypy/mypy.lock>
13:03:31  13:03:31.13 [INFO] Completed: Building 4 requirements for requirements.pex from the 3rdparty/default.lock resolve: click, pantsbuild.pants.testutil==2.21.0, pantsbuild.pants==2.21.0, pytest
13:03:31  13:03:31.18 [INFO] Starting: Building requirements_venv.pex
13:03:32  13:03:32.72 [INFO] Completed: Building requirements_venv.pex
13:03:34  13:03:34.63 [INFO] Completed: Typecheck using MyPy - mypy - mypy succeeded.
13:03:34  Success: no issues found in 9 source files
13:03:34  
13:03:34  
13:03:34  
13:03:34  ✓ mypy succeeded.
13:03:34  13:03:34.74 [INFO] Starting: Building pytest.pex from <resource://pants.backend.python.subsystems/pytest.lock>
13:03:34  13:03:34.77 [INFO] Starting: Building 3 requirements for requirements.pex from the 3rdparty/default.lock resolve: pantsbuild.pants.testutil==2.21.0, pantsbuild.pants==2.21.0, pytest
13:03:34  13:03:34.77 [INFO] Starting: Building requirements.pex
13:03:34  13:03:34.86 [INFO] Canceled: Building pytest.pex from <resource://pants.backend.python.subsystems/pytest.lock>
13:03:34  13:03:34.86 [INFO] Starting: Building pytest.pex from <resource://pants.backend.python.subsystems/pytest.lock>
13:03:36  13:03:36.38 [INFO] Completed: Building requirements.pex
13:03:36  13:03:36.52 [INFO] Completed: Building pytest.pex from <resource://pants.backend.python.subsystems/pytest.lock>
13:03:36  13:03:36.55 [INFO] Starting: Building local_dists.pex
13:03:37  13:03:37.55 [INFO] Completed: Building 3 requirements for requirements.pex from the 3rdparty/default.lock resolve: pantsbuild.pants.testutil==2.21.0, pantsbuild.pants==2.21.0, pytest
13:03:38  13:03:38.05 [INFO] Completed: Building local_dists.pex
13:03:38  13:03:38.10 [INFO] Starting: Building pytest_runner.pex
13:03:38  13:03:38.10 [INFO] Starting: Building pytest_runner.pex
13:03:39  13:03:39.64 [INFO] Completed: Building pytest_runner.pex
13:03:39  13:03:39.73 [INFO] Completed: Building pytest_runner.pex
13:03:40  13:03:40.09 [INFO] Completed: Run Pytest - src/.../x:tests - succeeded.
13:03:42  13:03:41.70 [INFO] Completed: Run Pytest - src/.../y:tests - succeeded.
13:03:42  
13:03:42  ✓ src/.../x:tests succeeded in 0.43s.
13:03:42  ✓ src/.../y:tests succeeded in 1.91s.

# --vvvvv--  Package begins here  --vvvvv--

13:03:42  13:03:41.82 [INFO] Starting: Building 1 requirement for x.pex from the 3rdparty/default.lock resolve: click
13:03:42  13:03:41.86 [INFO] Starting: Building build_backend.pex from <resource://pants.backend.python.subsystems/setuptools.lock>
13:03:43  13:03:43.30 [INFO] Completed: Building 1 requirement for x.pex from the 3rdparty/default.lock resolve: click
13:03:43  13:03:43.31 [ERROR] 1 Exception encountered:
13:03:43  
13:03:43  Engine traceback:
13:03:43    in `package` goal
13:03:43  
13:03:43  ProcessExecutionFailure: Process 'Building 1 requirement for x.pex from the 3rdparty/default.lock resolve: click' failed with exit code 102.
13:03:43  stdout:
13:03:43  
13:03:43  stderr:
13:03:43  Could not find a compatible interpreter.
13:03:43  
13:03:43  Examined the following interpreters:
13:03:43  1.) /usr/bin/python2.7 CPython==2.7.18
13:03:43  2.) /usr/bin/python3.8 CPython==3.8.10
13:03:43  
13:03:43  No interpreter compatible with the requested constraints was found:
13:03:43  
13:03:43    Version matches CPython==3.9.*
13:03:43  
13:03:43  
13:03:43  
13:03:43  Use `--keep-sandboxes=on_failure` to preserve the process chroot for inspection.

pantsbuild/pants

#20592 Allow extra env vars during nodejs package manager installation Issue created by kevinobruno Is your feature request related to a problem? Please describe. Pants doesn't allow passing extra env vars to the nodejs package manager during the installation of the packages, either through the

nodejs

subsystem or directly into the

package_json

target. When using

yarn

as the package manager, env vars can be very useful because almost all of the yarn settings can be set through env vars prefixed with

YARN_

, in replacement of having a

.yarnrc.yml

file. From yarn docs:

Finally, note that most settings can also be defined through environment variables
(at least for the simpler ones; arrays and objects aren't supported yet).
To do this, just prefix the names and write them in snake case:
YARN_CACHE_FOLDER will set the cache folder (such values will overwrite any
that might have been defined in the RC files - use them sparingly).

https://v3.yarnpkg.com/configuration/yarnrc Describe the solution you'd like Allow passing extra env vars either through

nodejs

subsystem and/or the

package_json

target. On

pants.toml

file:

[nodejs]
package_manager_extra_env_vars={"YARN_NODE_LINKER": "node-modules"}

and/or at the BUILD file:

package_json(
    extra_env_vars={"YARN_NODE_LINKER": "node-modules"},
)

Describe alternatives you've considered Creating a

.yarnrc.yml

file and using the

files

target to have this file on sandbox during the

yarn install

works. It does however require some additional steps to set those yarn settings and also only addresses the yarn package manager. .yarnrc.yml nodeLinker: node-modules

BUILD

files(
    name="package_config",
    sources=[".yarnrc.yml"],
)

package_json(
    dependencies=[":package_config"],
)

pantsbuild/pants

#22229 Very small typo in Pants docs Issue created by damian-gn Describe the bug There is a typo on this page in the docs: https://www.pantsbuild.org/stable/docs/python/overview/third-party-dependencies#only_binary-and-no_binary The first paragraph in the section refers to the setting as

resolve_to_no_binary

, which should be

resolves_to_no_binary

Pants version 2.25 OS n/a Additional info This was a confusing five minutes for me. 😵‍💫 pantsbuild/pants

#22234 package_json fails with an exception for cycle in dependency graph Issue created by nikhila-dwarakanath-zocdoc Describe the bug Given a package.json file like below:

{
     "name":"test",
     "scripts": {
           "depcheck": "yarn node ./depcheck.js",
     },
     "dependencies": {
           "depcheck": "^1.4.7",
     },
}

I have a package_json target with a node_build script for this script named

depcheck

. Getting this exception below:

[ERROR] 1 Exception encountered:

Engine traceback:
  in `package` goal

CycleException: The dependency graph contained a cycle:
   :package_json#test
-> :package_json#depcheck
-> :package_json#depcheck

To fix this, first verify if your code has an actual import cycle. If it does, you likely need to re-architect your code to avoid the cycle.

If there is no cycle in your code, then you may need to use more granular targets. Split up the problematic targets into smaller targets with more granular `sources` fields so that you can adjust the `dependencies` fields to avoid introducing a cycle.

Alternatively, use Python dependency inference (`--python-infer-imports`), rather than explicit `dependencies`. Pants will infer dependencies on specific files, rather than entire targets. This extra precision means that you will only have cycles if your code actually does have cycles in it.

If I update the name of my script to

dep-check

, it works fine. Pants version 2.27.0.dev2 OS MacOS Additional info Add any other information about the problem here, such as attachments or links to gists, if relevant. pantsbuild/pants

#22235 node_build_script failure during run goal with yarn Issue created by nikhila-dwarakanath-zocdoc Describe the bug A run goal on the node_build_script with yarn as a package manager fails with the below error.

Unknown Syntax Error: Command not found; did you mean:

$ yarn workspace <workspaceName> <commandName> ...

Currently it is executing -

yarn workspace <test_workspace> --cwd <path_to_workspace> run test

, ideally it should execute this way -

yarn workspace <test_workspace> run test --cwd <path_to_workspace>

. Here is the code where I suspect the run goal is failing. There are some differences in the

run_node_build_script

defined in package goal here and in run goal here. Do we want to standardize the logic across these goals for the

run_node_build_script

? Pants version 2.27.0.dev2 OS MacOS Additional info Add any other information about the problem here, such as attachments or links to gists, if relevant. pantsbuild/pants

#22239 pants 2.26.0 lockfile issue with requirement using vcs-support url fragments Issue created by jcrobak Describe the bug Python generate-lockfiles fails for source requirements using

#subdirectory=

(ref: https://pip.pypa.io/en/stable/topics/vcs-support/#url-fragments) Pants version 2.26.0 OS MacOS, Linux Additional info Here's a minimal repro: set -e # Generate BUILD cat << 'EOF' > BUILD python_requirements( source="requirements.txt" ) EOF # Generate requirements.txt cat << 'EOF' > requirements.txt opentelemetry-resource-detector-container@ git+https://github.com/open-telemetry/opentelemetry-python-contrib.git@v0.53b1#subdirectory=resource/opentelemetry-resource-detector-container EOF # Generate pants.toml cat << 'EOF' > pants.toml [GLOBAL] pants_version = "2.26.0" backend_packages = ["pants.backend.python"] [python] enable_resolves = true interpreter_constraints = ["==3.12.*"] resolves = { python-default = "python-default.lock" } EOF pants generate-lockfiles Upon inspecting the sandbox for generate lockfiles, pex is invoked with:

$'opentelemetry-resource-detector-container@ git+<https://github.com/open-telemetry/opentelemetry-python-contrib.git@v0.53b1>'

(Note the missing "#subdirectory=...`) When using Pants 2.25.0,

pants generate-lockfiles

succeeds. Similarly, when I inspect the sandbox, pex is invoked correctly:

$'opentelemetry-resource-detector-container@ git+<https://github.com/open-telemetry/opentelemetry-python-contrib.git@v0.53b1#subdirectory=resource/opentelemetry-resource-detector-container>'

Workaround In my case, it seems that using:

python_requirement(
     requirements=[
         "opentelemetry-resource-detector-container@ git+<https://github.com/open-telemetry/opentelemetry-python-contrib.git@v0.53b1#subdirectory=resource/opentelemetry-resource-detector-container>"
     ]

does work as expected. pantsbuild/pants

#22241 Trying to migrate a project using pants 2.14 to latest (2.26) with custom python plugin New discussion created by adamhadani Hey all, I'm trying to migrate an existing monorepo using Pants

2.14.0

to the latest (

2.26.0

). I'm running into some issues with adapting an existing pants plugin we have I hope I can get some help with. I've worked through some issues already to do with import changes and convention changes e.g. using

.rules()

instead of

SubsystemRule(...)

but now getting a somewhat more cryptic error: ❯ pants 091930.20 [ERROR] Rule entry (TaskRule(output_type=<class 'dynamic_version.main.DynamicVersionSubsystem'>, parameters=FrozenDict({}), awaitables=(Get(ScopedOptions, Scope, ..),), masked_types=(), func=functools.partial(<function _construct_subsystem at 0x107977d80>, <class 'dynamic_version.main.DynamicVersionSubsystem'>), canonical_name='construct_scope_versioning', desc=None, level=<LogLevel.TRACE: 'trace'>, cacheable=True),) had an unexpected type: <class 'tuple'>. Rules either extend Rule or UnionRule, or are static functions decorated with @rule. The plugin file is quite compact so attaching here for completeness. It tries to basically create dynamic versioning for python packages: import os from pants.backend.python.util_rules.package_dists import SetupKwargs from pants.backend.python.util_rules.package_dists import SetupKwargsRequest from pants.engine.rules import rule, collect_rules from pants.engine.target import Target from pants.engine.unions import UnionRule from pants.option.option_types import StrOption from pants.option.subsystem import Subsystem class DynamicVersionSetupKwargsRequest(SetupKwargsRequest): @classmethod def is_applicable(cls, _: Target) -> bool: # We always use our custom

setup()

kwargs generator for

python_distribution

targets in # this repo. return True class DynamicVersionSubsystem(Subsystem): options_scope = "versioning" help = "Dynamic version subsystem - used when generating python package version" python_version = StrOption( default="0.0.1.dev1", help="version to use when publishing python packages", ) def rules(): return [ *collect_rules(), UnionRule(SetupKwargsRequest, DynamicVersionSetupKwargsRequest), DynamicVersionSubsystem.rules(), ] @rule async def setup_kwargs_plugin(request: DynamicVersionSetupKwargsRequest, dv_subsystem: DynamicVersionSubsystem) -> SetupKwargs: """ This function dynamically adds a version In order to pass the version in """ return SetupKwargs( {**request.explicit_kwargs, "version": dv_subsystem.python_version}, address=request.target.address ) any help appreciated.. pantsbuild/pants

Comment on #22241 Trying to migrate a project using pants 2.14 to latest (2.26) with custom python plugin Discussion answered by adamhadani Update: figured out the issue with the help of Cursor IDE (AI for the rescue!) . Needed to have

*DynamicVersionSubsystem.rules()

rather than

DynamicVersionSubsystem.rules()

, e.g. unpack it myself. Nice. pantsbuild/pants

#18491 Run `terraform apply` on `publish` Issue created by ndellosa95 Is your feature request related to a problem? Please describe. Similar to my issue for

terraform plan

here, it would be great if we could use

pants publish

to call terraform apply. Describe the solution you'd like

pants publish

calls

terraform apply

. Describe alternatives you've considered

pants experimental-deploy

also seems like an appropriate goal for this feature. pantsbuild/pants

#22244 Shell Completions - script produced by `pants complete` for zsh is failing Issue created by gdfast Describe the bug • the completions script produced by

pants complete --shell=zsh

(doc link) fail to produce completions for zsh because the first line –

#compdef _pants_completions pants

is commented out. If you type

pants

and hit tab, it won't auto-suggestion or complete any goals. • If you uncomment the first line and source the produced script for zsh, the completions are not very intuitive. If I type

pants test

into the shell and hit tab, it will only continue to suggest more pants goals, but I want to add a system path in order to select target(s) Pants version 2.26.0 OS MacOS 15.4.1 Additional info Discussion here: https://pantsbuild.slack.com/archives/C046T6T9U/p1746807710037739 Uncommenting the first line fixed the issue pantsbuild/pants

#22246 performance issue in pants.backend.docker.utils.suggest_renames Issue created by vito-laurenza-zocdoc Describe the bug While building a docker container image which requires a large directory of many files (283488 files and 32382 directories) in the docker context, we noticed a BIG slow down in the duration of

package

goal. In our case, the

package

goal was taking 20-40 minutes to complete. Upon debugging, we discovered the source of this slowdown was due to the

pants.backend.docker.utils.suggest_renames

method. Using local pants source, we commented out the offending call in the docker build context creation, and the

package

goal completed quickly. Pants version 2.27.0.dev3 OS Found this on MacOS, but probably exists on Linux too. Additional info N/A pantsbuild/pants

#22247 Restore `pex_binary` `resolve_local_platforms` due to use with `complete_platforms` Issue created by huonw Describe the bug We had a mistaken impression about the behaviour of the

--resolve-local-platforms

PEX flag, where we assumed it only applied for the

--platform

flag, but it is actually also used for `--complete-platform`: #20823 (comment) We should thus consider restoring it by reverting #21416. (Possible work-around: providing the flag via `extra_build_args=["--resolve-local-platforms"]`: https://www.pantsbuild.org/stable/reference/targets/pex_binary#extra_build_args) Pants version 2.24.0 onwards (#21416) OS All Additional info N/A pantsbuild/pants