friendly ping on https://github.com/pantsbuild/pants/pull/17347 would like to get it off my table, to make room for new stuff.. 😉

Silly loaded question here. The bash completions have been sitting on my "need to release" pile for a while now, because there are a bunch of discussions around how/whether to export, how to handle each repo separately, etc etc. I think there is an adequate use case to experiment with dynamically creating completions on tab (which I think Jacob suggested months ago). Solves all kinds of problems with per-repo differences, detecting updates as they're made, etc. However, on my machine that might mean 1-2 seconds lag after tab. Maybe less on M1s (and my soon-to-be, M2).

Mostly FYI in https://github.com/pantsbuild/pants/pull/18052 Both

Target

and

Field

are switching from

frozen_after_init

to be vanilla

frozen

`dataclass`es. Non-dataclass subclasses of frozen dataclasses are not themselves frozen, but their frozen attributes are. All this means is people can now attach arbitrary values onto their instances of their subclasses. This isn't any different from other

frozen

dataclasses. I'm only noting it because I have to remove some lines from a test that tested this behavior. Again, still can't assign to any of the dataclasses fields. Also

__init__

is

final

I notice that the

publish-tag-to-commit-mapping

CI job failed for 2.15.0rc2, yet the mapping exists (and installing that version with scie-pants succeeds).

OK, so perhaps my first

scie-pants

feature request.. detect and invoke

./pants

if present..? 🧵

Haven’t looked into this just yet, but checking if anyone else has given any thought to this. Does the Pants GH action need to update any caches if moving to

scie-pants

? I’m assuming we don’t want to download the same pinterpreter if the

scie-pants

version hasn’t changed?

@enough-analyst-54434 we have a

bump_version.sh

script in the brew tap for updating the scie-pants version and sha sums, so if we could hook that up to your release action I think it’s not too far off to automate this.. I can look into it.

@ancient-vegetable-10556 Were you able to gist that NodeJS npm example?

kicking off the weekly dev release

Will do a 2.15.0rc3 once the last cherrypick is in

Where should more narrative-style release notes be placed for 2.16 regarding the Go changes in 2.16?

Update: • I'd love to start work on the "big file store" if I get time, but thats not likely • I'd also love to start some other fun work, but also not likely. • PR will be going up to deprecate

frozen_after_init

soon • I'll probably tackle https://github.com/pantsbuild/pants/issues/18090

is dependency inference environment-aware?

RFR https://github.com/pantsbuild/pants/pull/18132 This is a new

stevedore

backend for python projects that use openstack/stevedore (like StackStorm). Sorry for the size, normally I try to break PRs into smaller chunks. This time I needed to show holistically how it all fit together so that the implementation can be refined and improved without losing any of the functionality I depend on. 🙂

Heads up that I propose to rename pantsup.sh to the more descriptive get-pants.sh, for the reasons mentioned in the PR: https://github.com/pantsbuild/setup/pull/141. Basically punnery must give way to utility, now that we're suggesting checking the script into the repo for security reasons.

2.16 has been delayed for quite a while at this point: it’s had 7 dev releases, although in wall clock time, it’s been in development since ~Nov 1st (not terribly surprising with the holiday, but!) i think that we should consider bumping the experimental shell command stabilization to 2.17, and cutting 2.16.x this week.

On that note, I’ve put my preferred course of action on stabilising

shell_command

into words over at https://github.com/pantsbuild/pants/discussions/18082#discussioncomment-4833668 — If we can get some eyes on this, I’d appreciate it!

Would someone please mash the "restart from failed" button on this run? https://github.com/pantsbuild/pants/actions/runs/4069338777 The failures seem unrelated to this PR: https://github.com/pantsbuild/pants/pull/18132

I'm reading up on synthesized targets. My recent stevedore PR adds inferred dependencies on the python implementations for a subset of the entry points of

python_distributions

I wonder if it would be good to create synthetic targets for each of the entry points on the

python_distribution

and then infer dependencies on those instead of on the underlying python code. One of the rules generates an entry_points.txt file for

python_tests

. If there were synthetic entry point targets, then that rule could look for any direct or transitive dependencies on these synthetic targets instead of looking for the

python_distribution

and descending into the field to discover the entry points. This way, if test depends on the distribution itself, the entry_points.txt would get all of the entry points, not just the selected ones inferred by my plugin. And that would mean only one rule would generate that file so that two rules do not have to cooperatively choose which one generates the file. Or maybe instead of a synthetic target, we could reimagine

python_distribution

as a hybrid target generator that is both a target and generates these entry point targets. In any case, I think this would be a future enhancement - I don't want to do it in my current stevedore PR. But I'm imagining the future of it. @curved-television-6568 what do you think?

Do we really need this as INFO log?

07:40:16.66 [INFO] Starting new nailgun server with cmd: "/bin/bash", args ["__jdk/jdk.sh", "__java_home/bin/java", "-cp", "__jdk/com.martiansoftware_nailgun-server_0.9.1.jar:__toolcp/com.fasterxml.jackson.core_jackson-annotations_2.12.4.jar:__toolcp/com.fasterxml.jackson.core_jackson-core_2.12.4.jar:__toolcp/com.fasterxml.jac...........

Update to the init-pants github action so it works with the new scie-pants installation method: https://github.com/pantsbuild/actions/pull/16

So good news: Looks like we're going to get a "large file store" which will make writing/reading large files faster and work outside of the daemon Bad news: Looks like we're replacing speedy hardlinks with symlinks (which caused several issues in Pants' repo due to dogfooding) PR 🙂

The project has an interesting concept they call Unity where they have setup external projects using CUE as part of their regression test suite, meaning they’ll get early feedback from those tests when making releases if they have broken something that users rely on.

has anyone run across an error like this before?

stderr:
The virtualenv at /home/color/.cache/pants/named_caches/pex_root/venvs/499e7af10646cae90c3309114f8afb20270ce346/6907946b76533282134681624b0b55433bbbaeff.lck.work is not valid. No site-packages directory was found in its sys.path:
/opt/python/3.8.14/lib/python38.zip
/opt/python/3.8.14/lib/python3.8
/opt/python/3.8.14/lib/python3.8/lib-dynload
/opt/python/3.8.14/lib/python3.8/site-packages

we just hit it in CI for the first time. wondering if it’s another mysterious non-atomic locking issue like the error we’ve been chasing @enough-analyst-54434

Prep for 1 2.15.0rc3: https://github.com/pantsbuild/pants/pull/18156

I think I need help with cleaning out some caches on our MacOS runners for

scie-pants

https://github.com/pantsbuild/scie-pants/pull/75#issuecomment-1414522723 cc @happy-kitchen-89482 ?

I'm going to be at FOSDEM this weekend if anybody wants to meet up and talk Pants.

@witty-crayon-22786 I think I addressed your feedback on https://github.com/pantsbuild/pants/pull/18132 Could you give it a once over and, if it's good enough, mash the merge button please?

If you chose, you now can run

pants

in the pants repo, you just need to update to the latest release (

SCIE_BOOT=update pants

or if you brew, you know how to update brewed things).

@witty-crayon-22786 https://github.com/pantsbuild/pants/pull/18165 is the last PR from me blocking cutting 2.16