thinking we can figure out how to pull those into github Projects when we meet to discuss milestones

@rough-minister-58256 uploaded a file:

🎉👌🍾

there's a failing test in the internal release which i'm fixing now

actually makes me very angry that the test is failing (or rather the reason that it is failing) but the replacement i have will be amenable to converting to use the new ctypes native code targets easily in the next internal release

^lol @ being angry ever how absurd

i liked the dag constructor that’s just an

@rule

would anyone be mega angry if i made a pr that changes instances of the word "failure" in test names to something else like "fails" or whatever so i can control+f travis logs more easily or am i doing something silly

oh and i wanna make a pr that just adds an

as_tuple()

method that calls

__getnewargs__()

to

datatype

so you can do tuple destructuring on that like

a, b = my_datatype_instance.as_tuple()

and i also wanna add an immutable

copy()

or

modify()

method to

datatype

to do what thrift copy methods do, which is to create a new object of the same type with whatever fields are provided to the method, i feel like that could make a lot of the native dependency injection much cleaner

and once rules can have multiple subjects as apparently was my master plan all along that will allow me to remove a ton of indirection

@aloof-angle-91616: daniel added a script to scrape travis logs

perfect!

subsystem dependencies map pretty perfectly to multiple-subject rules

which basically means i can thread together this "native toolchain" nonsense for now without just being able to add `Select()`s, but i'm ready for the future

i was thinking about querying the rule/product graph and what user-facing interfaces might want to do that

and i was thinking of (1) something like

dependees

for rules, which is "i want everything that statically exists (in the rule graph) satisfying these filters" (2) something like task/rule progress display which is "i want some selection of products in flight" (3) something like

Select()

for an

@rule

which is "i want this specific product which there should only be a single way to obtain in the subgraph this rule is contained in"

couldn't figure out whether there could be any unification among the api for specifying these types of queries, i.e.

Select(MyProduct)

could specify a query to the rule graph for all rules which produced

MyProduct

, which might be something we could have a cli goal for (seems like a query that might be pretty useful to have while developing a plugin)

i guess then i thought like "ok, what if you could configure the types of rules/weights/whatever you see when pants visualizes progress in pants.ini?" and that seemed neat and then it also seemed like another place you could effectively use a unified query method e.g.

--task-progress-display-weights="[('select', 'c-compile', 100), ('select', 'zinc-compile', 200)]"

to that you want zinc compilation to go to the top of progress displays, and c compilation as well, but less. expanding then what kinds of selectors are available (more than just

'select'

) and potentially expanding what you can specify as a weight for other types of ordering is interesting to think about (not thinking of being able to or wanting to do this as necessarily happening anytime soon)

with the contrast being: rule graph vs product graph, as well as "there is a single correct answer" vs "this is a parameterized summary"

also, order of the output matters for a "display top N" query, but not for the other 2 types

but i guess my sticking point was: would we ever want anything other than

Select()

to specify products in an

@rule

? because we have

yield Get(...)

now it seems like we could even slim it down to just

@rule(ProductType, [SubjectA, SubjectB])

? unsure if i'm missing something obvious

and like not matching subjects exactly feels weird and wrong

well, maybe not, because that could be how we do rule graph introspection

hmmmmmmmmmmmmmmmmmm

also realizing that every product graph query is an "in-flight" product graph query because of the daemon

conclusion: the daemon allows pants to fly

@witty-crayon-22786 Note that some of my comments on https://github.com/pantsbuild/pants/pull/6013 are “outdated” 🙂

Whoops. Ok, thanks.