no rush

i'll make it work if something is breaking

i'm in the "change everything at once" phase, haven't even tried to run the code yet

writing `@rule`s is so nice i cannot believe it

and this?????

class ListAndDieForTesting(Subsystem):
  """A fast and deadly variant of `./pants list`."""
  options_scope = 'list-and-die-for-testing'

@console_rule(ListAndDieForTesting, [Select(Console), Select(BuildFileAddresses)])

the correspondence between goals and `options_scope`s is perfect

like the

@console_rule

returning a subsystem is i think about as key as the

Select(Console)

-- the

Select(Console)

part says "we need exclusive access to the global singleton tty", while the

@console_rule(ListAndDieForTesting, ...)

says "this rule is intended to list some things and perform some side effects (terminal i/o)"

and that's all very useful information

this was hinted at above, but do we see any need for explicit

Select(...)

at this point (as opposed to tuples)? i'm 1000% fine with the current API, i'm just wondering since we've had the coroutines brainblast and were able to make that logic more granular (compared to e.g.

SelectDependencies

), whether we want to move to e.g.

@rule(MyProduct, [MySubject, MySubsystem])

. i really don't like it when projects move too fast from primitives to higher-level abstractions, and i don't want to remove the ability to extend the selection later (although i guess we could do the normal thing we do with like subsystem dependencies and interpret a class

MySubject

as

Select(MySubject)

in the

@rule

declaration)

e.g.

@rule(MyProduct, [MySubject, Select(SomethingElse)])
def whatever(...):
  # ...

could maybe just expand to:

@rule(MyProduct, [Select(MySubject), Select(SomethingElse)])
def whatever(...):
  # ...

the rust bootstrapping shell scripts haven't so far required anything other than translation, good shell scripts are good

might have found a bug in the engine in

3fbb0e377212558cca7b4d4aca586e2770249431

or earlier which i remember i was going to make a pull request comment on, but didn't. going to verify and then fix

i was wrong about what i thought the bug was (the scheduler didn't handle some transitive rule relation correctly, or something), but now i think it's an issue when loading rules from plugins, which i had hacked on, so making an integration test now

so no bug, sorry, but i do have some tests to add. i think it's because

PathGlobsAndRoot

doesn't have an intrinsic, which i'm going to add now

blah this is too hard

i'm trying to

yield Get(Snapshot, PathGlobsAndRoot, my_globs_with_root)

and this is because the files i'm trying to get are for cargo and rustup etc

i get why the rule graph can't satisfy that

hm nvm

got it

lmao

first try

https://github.com/pantsbuild/pants/pull/6891 made a rust ruleset to bootstrap the native engine

and also let plugins declare rules because there aren't actually any blockers for that i think: https://github.com/pantsbuild/pants/pull/6892

also the error messaging when you can't satisfy a rule (in this case, i was trying to

yield Get(Snapshot, PathGlobsAndRoot, ...)

) made me waste several hours today because it just said "no installed rules could satisfy the selection" or something and i'm not sure where to change to make that better

@witty-crayon-22786 I really like the sound of removing

Select

from

@rule

signatures… What’s needed to do that?

Finally got to look at https://github.com/pantsbuild/pants/pull/6880 - super exciting!

Weird pantsd issue, does this ring any bells? I try to run

./pants <anything>

and get this error:

WARN] caught OSError([Errno 1] Operation not permitted) during attempt to kill -15 60!
WARN] caught OSError([Errno 1] Operation not permitted) during attempt to kill -9 60!

This is pants trying to kill pantsd (whose pidfile indeed contains 60)

HOWEVER - pid 60 actually belongs to

configd

, a macos system process

And here’s where it gets really weird: