What do other developers think of GitHub Actions caching? The big gotcha are caches are immutable, so Pants normal caches don't quite match explicitly. The Pants setup dir can be cached based on Pants version. Then theres the other cache dirs. My thought was to include both in the key: • The branch name. This means for PR runs, the first build is heavy, and subsequent builds are fast_er_ (since the code from push to push should share most of the files with the first push) • This week (as an int). This would clear the cache every week or so so they dont get too stale IIUC restore keys correctly, if Pants had a cache trimming feature, that could be used as well.

Also, how important do we think the `flake8_pantsbuild`'s "constant-in-a-conditional" check really is? It's the only checks enabled in Pants (the other checks are disabled locally or by the plugin itself). E.g.

if True or x:
    ...
if x and False:
    ...

New discussion on a proposed design doc for adding a

__defaults__

construct in BUILD files: https://github.com/pantsbuild/pants/discussions/15809

Hey, Poetry 1.2 has made lots of improvements recently to issues that motivated us to use Pex lockfiles, including

--find-links

support, fixing

export

for "bifurcated requirements", and fixing the cache writing What do we think about permanently for at least now keeping

[python].lockfile_generator = {"pex", "poetry"}

? It's much more complex code for us, but it may ease incremental adoption because you can still use requirements.txt-style locks

Hi! Now that in-repo docs have landed as an experiment (https://github.com/pantsbuild/pants/pull/15810), it's important folks don't directly save edits to Readme.com without updating GitHub. Those won't be persisted @ancient-vegetable-10556 and I had the idea of tightening up the number of admins on Readme.com so that fewer people have to remember this gotcha. Thoughts?

Anyone have thoughts on allowing

./pants run <tool_subsystem>

? I want to know what args

black

or

pylint

accepts. Running

./pants run black -- --help

would be AMAZING (Also this could possibly replace

repl

, if we support the REPLs in

run

. Huzzah less goals? I could do this with my own separate

pex_binary

and resolve, but I think we all understand how nasty that it 🙂

It looks like 2.12 unifies fmt/lint under the hood: https://github.com/pantsbuild/pants/pull/14903 How will this tutorial change to account for that? https://www.pantsbuild.org/docs/plugins-fmt-goal#3-create-fmt-and-lint-rules Has anyone looked at that? ie, can I skip writing a lint rule, and just write a fmt rule?

FYI I'm going to archive https://github.com/pantsbuild/flake8-pantsbuild now that we no longer use it

Reminder that today is the last day to sign up to vote in the upcoming PSF board election: https://pantsbuild.slack.com/archives/C0D7TNJHL/p1654802988300799

Woot! GitHub is going to be adding official M1 support https://github.com/github/roadmap/issues/528

OK. This is a little odd, but what if a

fmt

tool adds a new file? Should that be reported in the list of changed files? Pants 2.12 shows the files that fmt changed, but the changed list only includes files that were present in both input and output digests. I dove into the code to figure out what does the diff. This is where the diff is displayed: https://github.com/pantsbuild/pants/blob/main/src/python/pants/core/goals/fmt.py#L116-L119 And this is where the actual diff happens, populating the list of

changed_files

: https://github.com/pantsbuild/pants/blob/main/src/rust/engine/fs/src/directory.rs#L599-L605 I believe that rust code only adds files to

changed_files

if the file is in both

ours

and

theirs

during diff... but I don't understand some of the syntax of rust, so I'm not sure.

Just throwing this out into the ether... Is anyone use Pants in an embedded linux workflow, from a bootloader/rootfs generation workflow? I typically use buildroot, but that falls over if you need to use Debian - then I end up falling back into a world of nasty shell scripts everywhere

https://www.pantsbuild.org/docs/reference-python_test lists

dependencies

twice 😮

We have quite a few cases in the codebase of WrappedTargetRequest with

description_of_origin="<infallible>"

it sounds like we’re on for

2.13.0a0

tomorrow

Only outstanding TODO on the Python

run

PR is how to switch between sandbox mode. The friendliest solution IMO is a new

run

flag, however this flag is only relevant when `run`ning a "scripting" language ("compiled" languages wouldn't benefit). So pros/cons. The alternative is a field on

python_source

and

python_test

targets, which is a bit funkier and has no obvious CLI support (we could add a "default" CLI option to

python

, but now we're talking even more machinery) Thoughts y'all?

With the

run

PR https://github.com/pantsbuild/pants/pull/15849,

[python].tailor_pex_binary_targets

is no longer very useful. Thoughts on what should happen? cc @happy-kitchen-89482

OK, I think that the

__defaults__

PR is ready for review. Unless I’ve missed something, all points raised and covered in the design doc are now implemented. Thanks for all the valuable feedback during the design work. https://github.com/pantsbuild/pants/pull/15836

Naming convention question - getting prepped to write some compiler(s) and I want to make sure I'm using reasonable target names: I see

_binary

and I'm assuming that's referring to an artifact that is directly executable? For library-centric, I see

_package

and

_distribution

Then I see a

go_mod

jvm_artifact

and `jvm_war`and maybe

deploy_jar

- which seem to be language-centric So, if I'm creating a static or shared library (let's say C++ or Swift), should I call that

_library

? Because that also used to be an alias for something...

python_sources

maybe?

thanks a lot @curved-television-6568. were you thinking of targeting

2.13

, or should landing wait until after

2.13

has been cut? probably sometime over the weekend

I think this could use a few dev releases to smoke out any issues, so would prefer to land it post 2.13 is cut.

pheew… glad to hear it, heh. bit of a mad dash for 2.13 here

thanks: will review over the weekend.

I think https://www.pantsbuild.org/v2.12/docs/release-process#step-2-update-this-docs-site may be incorrect? I'm doing 2.13.0a0 and there's no 2.13 docsite - the release page suggests it should've been created at 2.13.0.dev0 but I don't think that's what we actually do?

Minor release script fixups: https://github.com/pantsbuild/pants/pull/15875

Just watched . I guess a confirmation of a good choice of PyO3 for Rust Python bindings used in Pants (that's what is used, I believe) - authors of the Python

cryptography

package talk about their Rust adoption, they have used PyO3 as well. Great talk to watch for anyone who wants to learn from their experiences wrt to Rust.

Rule graph question 🧵 about input Params..

@hundreds-father-404 I’m looking at the specs parser, and wonder what the

convert_dir_literal_to_address_literal

does? When do I want that to be true/false?

Hello, I put together a document describing the proposal for an

experimental-deploy

goal and a PoC implementation for the Helm backend: https://docs.google.com/document/d/17wZRjiIxM5918ybC_0EnKY42qwd47-1ZporBdua8vRQ/edit?usp=sharing My apologies for how drafty the document feels, having a mix of plenty at my plate and family issues at the moment so I couldn’t dedicate much time to it. Hope that the document plus the PoC Pull Request are useful to trigger a conversation.

@happy-kitchen-89482 added

run_in_sandbox

field to

pex_binary

, which currently hasn't been put in a stable release yet. https://github.com/pantsbuild/pants/pull/15849 reverts that change in lieu of another change that offers the same behavior, but in a different way. We need to figure out our path forward for the current release: 1. Leave the feature, then do a full deprecation cycle and remove 2. Change the field to

experimental_...

so we could pull the plug without deprecation 3. Get PR 15849 in ◦ I'm only waiting on docs addition and an open TODO I want feedback on As the author of the PR, my vote will obviously be 3 😊 , but I'd like us to be intentional on our path forward.