Also, where do I find a bunch of examples of rules?

not sure if it’s published on the docsite, but you can view the render in github directly: https://github.com/pantsbuild/pants/blob/master/src/python/pants/engine/README.md

tests/python/pants_test/engine/examples/planners.py

has a bunch of example/prototype rules, but in general they’re a bit scattered. can scan for usages of

pants.engine.rules.{SingletonRule,TaskRule}

and

pants.engine.selectors.{Select,SelectDependencies,SelectProjection,SelectVariant}

subsystems are likely to be most similar to

SingletonRule

thx

@happy-kitchen-89482 : very happy to answer questions about writing Rules if you're still interested in tackling the config-on-engine task

Yeah, I’m looking at it but it’s making my brain spin

yea... we definitely need either more examples, or more explainable sugar

@happy-kitchen-89482 : i can spiel about this a bit more in writing somewhere, if you think that would be useful? sketch out what i think it might look like?

@fancy-queen-20734 : i'm sure you've thought a lot about this, but it is just occurring to me that it is super, super weird that the

subject

is part of a Node's identity, even if the Node doesn't directly use the subject.

hm. Well, it’s part of the graph’s id for the node too. I suppose you don’t need the subject itself necessarily.

I basically want to express something like “To produce an Optionable instance I need ScopedOptionsValues for the scope; To produce ScopedOptionsValues I need OptionsValues; To produce OptionsValues, I need [Flags, Config, Environment], to produce Config I need [list of ConfigFiles], etc. ” I’m still figuring out what that means in terms of “subjects” (which is still a mysterious concept to me). Also, I’m not clear on how the initial values are provided (e.g., “here’s the list of config files”, “here’s the command-line flags”) from which the engine can flow forward.

I suppose you could chunk subgraphs by their subject instead of having the nodes within the subgraph know about them

Some nodes don’t need the subject because the things they depend on are not dependent on the concrete subject values

I suppose if we widened the prolog-ish nature of things, instantiated subjects are just concrete values for variables used in look up expressions

@happy-kitchen-89482 : if the list of "config files" is hardcoded, it might be a literal

PathGlobs.create(include=['pants.ini'])

that you request the contents of

^ is a very good question, and probably relates to bootstrap options in some way

Well, how is this done in general?

At some point some products have to be provided by the filesystem or whatever

They have to just “be there”, so products can flow forward from there

the "initial values" were recently clarified a bit. if they are not hardcoded in the Rules themselves, then they will be provided at the root of the execution when a call comes in to the engine as

selector.product_request(Optionable, subject)

I think a tutorial would be helpful

that other doc has a lot of irrelevant stuff about the old engine, and historical context

"initial values" provided by the caller are explicitly labeled as such by being declared as `RootRule`s

and it assumes that you understand what a “subject” is

Ah

RootRules

perfect

But yeah, a tutorial based on some contrived example would be really helpful

@happy-kitchen-89482 : the idea is essentially that anything that might be the subject of a root product request should likely have a

RootRule

declared