If anyone wants to pick up the non-utf8 env var baton, although

scie-pants

is fixed with the 0.8.2 release, Pants itself needs two Rust fixes to get things working. Those are documented in https://github.com/pantsbuild/pants/issues/19199 and these bugs are roughly birthday bugs; so how far back to pick will be something to decide.

I'm developing on a branch off of

main

, and pants does not seem to be using my

~/.pants.rc

file. Is there a way to dump the effective config to see what options pants is using and validate if the rc file is taking effect? If not, then there might be something ignoring the

[GLOBAL].*_dir

opts.

I'm convinced making

str

also an

Iterable[str]

in typing-land is dangerous. We've had a long-standing bug in our graph traversal algorithm (for secondary ownership) it seems... With that hint, can you find the bug? https://github.com/pantsbuild/pants/blob/b7dee2e576beb5a49790cf5c1803418624631c1a/src/python/pants/engine/internals/graph.py#L904 (Answer in 🧵 )

Almost done with the second modern-ification of the cherry pick automation. one thing I've realized is that testing this thing SUCKS. With a decent amount of hand-holding, One can use

act

, but it isn't ideal. Do people have thoughts on porting the user-run script to JS? So cherry-picking (when it fails to auto-pick) would be

pants --no-pantsd run build-support/bin/cherry_pick_one.js -- <arg1> <arg2>

(yummy dogfood). The upside is we can actually test some common code and have code re-use.

@enough-analyst-54434 has left the channel

I noticed that the tagging of a release as a “pre release” is somewhat inconsistent. Is it something that matters?

there are a few picks bound for 2.17.x: would be great to get them landed soon so we can cut release candidates.

Someone with experience using `jvm_war`: Context: I'm studying various fields to see if we could combine

content

with

dependencies

(actually looking at the feasibility to get rid of all of the

SpecialCasedDependencies

fields like

content

). If you put

file(s)

or

resource(s)

in the

jvm_war(dependencies=...)

field, are they ignored today (I hope the answer is yes)? Or do they somehow end up in one of the JARs on the classpath? It's not clear to me from reading through the rules.

A while back I saw some proposal on having different dependency graph types for different goals. (For example, in Python, check deps might include more modules than a test type). Has this gone anywhere?

Ooohhh Major Kudos to (new mainatiner) @worried-painter-31382 for the experimental JS support. I'm modernizing the Cherry-Picker GitHub Action using Javascript and wanted to put all the relevant code in-repo so I could test it (because testing actions is usually reserved for "in-prod"). It's such a breeze 🎉

Hello! I am on release rotation today. Would it be 2.18.0.dev1? Also I will probably start the process this evening.

I would love to get feedback from people on the What's New section in the 2.17.x release notes: https://github.com/pantsbuild/pants/pull/19168 (some feedback already but some more reviewers may ensure better release notes)

I've been scouring, looking for where the ideas around multiple dependencies fields vs some mechanism to tag dependencies within the same field has been discussed. I couldn't find any proposal that specifically addressed this. Does anyone have some pointers? (links to what I've found so far in 🧵 )

hmm the latest commit seems breaking for me:

commit 0aedb6b3559240c120ad3e09ee99a83b821e7351 (HEAD -> main, origin/main, origin/HEAD)
Author: Tobias Nilsson <tobias.jens.nilsson@gmail.com>
Date:   Sat Jun 3 19:04:01 2023 +0200

    javascript: Assign a default name to root nodejs resolves (#19047)

was able to run the command at the previous SHA. cc @worried-painter-31382

I noticed the 2.17 docs don't seem to be updated for 2.17.0rc0, e.g. I'd expect https://www.pantsbuild.org/v2.17/docs/google-cloud-function-python to include the changes from https://github.com/pantsbuild/pants/commit/d927fa1c200a7e0f41484e469964737155dab34c, but it doesn't seem to

docs/NOTES.md

has instructions on how to sync those up

that is a manual part of the release process, and really should be automated

Looks like https://github.com/pantsbuild/pants/pull/19110 never got picked to 2.16.x due to flaky CI. I jsut re-ran

OK. I think I got it all mapped out for my proposal for shifting how changelog generation happens: https://github.com/pantsbuild/pants/discussions/19247 It seems like a lot, but I wanted to make sure each step was clear. The upside is most of this can (and will) be automated, which is the reason for the change.

The recently released 2.17.0rc0 wheel doesn’t have the new

taplo

backend tool:

$ unzip -l pantsbuild.pants-2.17.0rc0-cp39-cp39-macosx_11_0_arm64.whl | grep taplo

even though the subpackage is in the repo at that tag: https://github.com/pantsbuild/pants/tree/601f885c7151f67875f7c9b523121ae8d3386379/src/python/pants/backend/tools

RFC: Running

taplo

on the Pants repo to format

.toml

files: https://github.com/pantsbuild/pants/pull/18998

Does anyone happen to have knowledge of GCF for the question below? For https://github.com/pantsbuild/pants/pull/19253, Benjy and I suspect I might need to run within the actual environment rather than being able to run within a docker image

PR to save our test reports to S3 so we can get data on slow/flaky tests in the Pants repo: https://github.com/pantsbuild/pants/pull/19262

I've found an interesting issue. Haven't quite figured out what is happening; but if I take my pants-backends repo and add

pants.backend.shell

as a backend, it crashes with rule graph errors on all unreleased versions I can test. Without the shell backend it works fine. Without the OCI backend it works fine. The combo itself is toxic. This repros on 2.16.0rc5, 2.17.0rc0. Wondering if this is related to

RunInSandboxBehavior

, just unexpected that it explodes like that. 2.16.0.dev2 is the last one that works.

Going to cut 2.16.0rc6 (hopefully the final RC!) soon unless anyone has any cherry-picks I should wait for.

🧪 So...... I think I might've crossed the Dr. Ian Malcom line here..... but I can now do high-level testing of GitHub Actions in Pants...

experimental_test_shell_command(
    name="Test auto-cherry-picker prereqs",
    command="./act workflow_dispatch -W .github/workflows/auto-cherry-picker.yaml -j prerequisites --input PR_number=17295 --env GITHUB_REPOSITORY=pantsbuild/pants",
    execution_dependencies=["//build-support/bin/act:bundled-act"],
    workdir="/",
    timeout=120,
)

Now I know I don't have broken YAML and my code executes reasonably well...

Based on https://github.com/pantsbuild/pants/pull/19249 Should we rename "bugfix" category to something like "user bugfix" or "postrelease bugfix"?

I walked through the release procedure, because it seems like lots of people are enthused / have ideas about automation in their heads, but maybe not the same ideas. I identified 3 potential pieces of automation that give smoother releases, sooner rather than later: 1. 'start release': workflow to update changelog, contributors etc. 2. 'tag release': workflow to cherry-pick ^ (if required) and add a git tag 3. augmenting existing release workflow: update docs site, publish PEX https://github.com/pantsbuild/pants/discussions/19279 has the details/analysis. (I am filled with hubris: I've never run a release. 😅)

So just tried out

2.16.0rc6

in CI, and we hit the same AWS token issue. Primarily because

botocore

apparently is inconsistent with casing of headers. 😠 I fixed the upstream PR to

botocore

, and I'll open a PR to Pants (which I'm going to bang on more thoroughly locally first) At this point is it even worth CPing to 2.16.x? People can copy the plugin locally as an in-repo plugin...

Is pantsbuild.org down for everyone?