@sparse-lifeguard-95737 I think we left some cruft in

test

between the old union

TestFieldSet

and the new union

TestRequest

. • Is

TestFieldSet

supposed to be a union? • Should the

TestSubsystem

be asking if

TestRequest

is in

union_membership

instead of

TestFieldSet

?

Oh yeah, there's a couple directions we could take this, but here's your teaser:

@convert_fields
@dataclass(frozen=True)
class Foo:
    x: Iterable[int] = convert_field(tuple)

x = Foo(x=[1, 2])  # mypy is happy

reveal_type(x.x)  # reveals Iterable[int]
print(type(x.x))  # prints <class 'tuple'>

I'm coming after you

frozen_after_init

😈

As an avid hater of new goals, is the plan to prefix goal names that should be rolled up elsewhere (someday) have a

preview

or

experimental

ala • experimental-bsp • experimental-deploy • experimental-explorer

Discussion about possibly simplifying Python lockfiles: https://github.com/pantsbuild/pants/discussions/17776

PANTS_* namespacing bike shed:

@witty-crayon-22786 I'm gonna try and look into the immut perf issues this week if I can, but I'm OoO starting Thursday. So might not get to it until next week

I have a (2x so far) reproducible case of https://github.com/pantsbuild/pants/issues/15312 in scie-pants CI for Pants 2.16.0.dev1+git298409b3 (298409b3a4d7914c29a3bea5098b55698967f658). This is not using --no-pantsd which some issue work that closed this issue out as dup seems to focus on.

Could I request someone retry the category job in https://github.com/pantsbuild/pants/pull/17782? Thank you!

Can someone help me out w/ this failure?

src/python/pants/init/load_backends_integration_test.py:tests failed in 450.00s.

https://github.com/pantsbuild/pants/actions/runs/3681659160/jobs/6228608674

For my own edification, have we ever, or would we ever consider dropping Pants support of Python 2? I've always been musing using LibCST to parse the AST for dep inference as it is much more powerful/robust. But it's Python 3 only. We could use different parsers for Py2 v Py3, but documentation+maintanance of that seems ripe for staleness/errors

Interesting topic of discussion: We've talked previously about "should Pants expose the transitive dep graph for 3rdparty things?". (this usually applies to Python). The answer is that although it is "neat" and would help you understand how a 3rdparty dep exists in an environment, it also involves parsing lockfiles or other extra work (which @enough-analyst-54434 rightfully reserves the right to change for PEX). I just ran into an interesting and slightly compelling case: I'm assigning system packages to targets and just hit where a transitive, but not direct, 3rdparty req requires

libfoo

. The only way to surface that is to declare each direct 3rdparty dep which transitively relies on the offending 3rdparty req has the dependency on

libfoo

instead of just the one transitive req. Not the end of the world by any stretch, but I don't like encoding assumptions that might change over time. Also not a compelling enough reason to tackle the Pants request, but an interesting discussion nonetheless

I see a new Classify Changes CI step, which seems to be consistently failing for me: https://github.com/pantsbuild/pants/actions/runs/3706006467/jobs/6280703870

@witty-crayon-22786 you're this week's releaser - head's up:

More scrutiny of the

./pants

script - `PANTS_TOML`:

@ancient-vegetable-10556 I’m back to playing around with

experimental_shell_command

+

yarn

, and hit another case of bad perf 🧵

Thread re deprecating the option `[python].resolves_generate_lockfiles`:

@witty-crayon-22786 @happy-kitchen-89482 re: https://github.com/pantsbuild/pants/discussions/17477 Would y'all be amenable to the new dep-inference-only opt-in process type? I basically have half the code written already, and most of the batched inference code, so it'd only be a few days off effort to try out

Hello all, over the last few days, I've poked a bit at remote caching, and have a proof of concept at https://github.com/pantsbuild/pants/pull/17840 that supports fine-grained "remote" caching to the Github Actions cache for GHA CI builds, and setups up infrastructure that should easily generalise to other blob stores (e.g. S3, GCS). Before I commit too much time into making it at all nice (the code there is very much proof-of-concept), is work towards this likely to be accepted? (The PR description has a bunch of discussion/examples.)

Is there a structure to follow for tests that expect a system binary, but that binary may not be available on everyone's machines? e.g. clang or gcc

On my machine,

scie-pants

reliably takes 150ms less than the pants script - which is fantastic!

finally got around to writing docs for the new batched-pytest functionality, if anyone can take a look 🙂 https://github.com/pantsbuild/pants/pull/17845

is it possible to add a new option for an existing Pants goal using the plugin API? E.g.

./pants dependencies --my-flag

. The docs show how to add an option for a new subsystem, but I wonder if one can hook up into an existing goal?

RFR https://github.com/pantsbuild/pants/pull/17849 make export stop deleting the entire

dist/export

dir on every run - only delete what is being actively exported (eg to export only one resolve at a time without clobbering the previous exports).

Having spent an hour (unsuccessfully) trying to unpick a unit test for a change that (apparently) drastically changes the rule graph in JVM land… I’ve noticed that there’s a bunch of modules that don’t declare their dependency rules in the

rules()

functions. So I was wondering if there’s enough information in the rule graph to statically generate correct and complete

rules

functions for a given module. Is there? What would it take to make that work?

Re: scie Would the intention be to keep the

scie-pants

centric stuff in the

nce

cache folder, and the lmdb_store + named_caches stay where they are in the

.cache/pants

folder?

How is the arm GHA runner going? I'd like to run pants in termux on my phone... Though, I suppose I'd also have to compile python, because termux only includes the latest python, which is 3.11 right now.

RFR https://github.com/pantsbuild/pants/pull/17711 allow each resolve to be exported for multiple python interpreters - with this change, export will only remove the virtualenv for the precise python version that is about to be exported. This way, I can have exported venvs for multiple python versions: python 3.6, 3.8, ...

Updates for this week: • Try and find time to debug the immut CI issues • I'm really hoping to find time to integrate

ruff

. It's like a dream come true lol (no literally I've had dreams about better/faster Python tooling) ◦ Supporting pylint codes is the straw that breaks my back here. I can't not look into it. I dislike the slowness of Pylint and the age it shows

Useless demo!

chrisjrn@chrisjrns-MBP example-python % ./pants_from_sources run ":reqs#black" -- an_source.py
reformatted an_source.py

All done! ✨ 🍰 ✨
1 file reformatted.
chrisjrn@chrisjrns-MBP example-python %

@witty-crayon-22786 I suspect that the CI timeouts from the immut PR had to do with contention of some kind. Just running a test alone has it completing in 200s, instead of the 1000s we saw when running all tests