in our case that might be the completion of named rules turn

Question

in our case that might be the completion of named rules turns into a log message but you might have too many of them

witty-crayon-22786 · Answer

< fast nail 55400> but to be clear i agree and that s been a user request

witty-crayon-22786 · Answer

just need to figure out what an appropriate unit is and it may not be a process

hundreds-father-404 · Answer

It often will not be a process For example it would be crazy to log every single requirements pex we ever build That s an implementation detail

witty-crayon-22786 · Answer

not sure whether the concept of log levels applies to named rules as well

hundreds-father-404 · Answer

Interesting I like it on first thought I agree it is very helpful to have the capability to permanently log when things like requirements pexes are set up One of the hard parts of developing V2 is that the info I need always leaves the screen before I need it Even taking screenshots to put in PR descriptions is tricky

hundreds-father-404 · Answer

Cc < hundreds breakfast 49010>

witty-crayon-22786 · Answer

it feels like there is an opportunity here to mostly discourage logging and to lean in on named rules that have various levels

witty-crayon-22786 · Answer

and which have a start and end

witty-crayon-22786 · Answer

this is not really that novel honestly the v1 API does it as well it just takes that structure and nests it

hundreds-father-404 · Answer

The one downside is that named rules can t have dynamic information because the string is set as a function decorator rather than in the body of the rule We used to have intentions for a Logger singleton Maybe we go back to that

witty-crayon-22786 · Answer

gt The one downside is that named rules can t have dynamic information because the string is set as a function decorator rather than in the body of the rule there was a solution designed for that i think

hundreds-breakfast-49010 · Answer

< witty crayon 22786> benjy had talked about the desirability of dynamically setting information about a rule within the rule itself

hundreds-breakfast-49010 · Answer

not as an annotation

hundreds-breakfast-49010 · Answer

< hundreds father 404> I ve been spending a lot of time looking at logging in both rust and python over the past few days

hundreds-breakfast-49010 · Answer

there s a lot of cruft in our abstractions which I m trying to get rid of

hundreds-father-404 · Answer

I agree Annotations aren t very helpful on their own The interesting piece is the dynamic information

witty-crayon-22786 · Answer

hundreds-breakfast-49010 · Answer

but once that s done I think it will be pretty straightforward to add more types of logging and make it clear where and how it will be output when pants is running

witty-crayon-22786 · Answer

so

witty-crayon-22786 · Answer

hundreds-breakfast-49010 · Answer

and yeah it s possible that the right thing to do is to discourage logging

hundreds-breakfast-49010 · Answer

but see < red balloon 89377> s comment on the v2 UI doc I made that perhaps for pants end users the most useful thing to see is the log lines rather than the swim lanes

witty-crayon-22786 · Answer

because as a reminder of where this Thread started how do you have a UI for things that don t have starts and ends

witty-crayon-22786 · Answer

< hundreds breakfast 49010> see < fast nail 55400> s comment

witty-crayon-22786 · Answer

that doesn t necessarily mean log messages

witty-crayon-22786 · Answer

it means log messages currently but only because we log exactly one place in the engine in the test runner

hundreds-breakfast-49010 · Answer

< witty crayon 22786> I think that s not a bad idea and that will hopefully be easier to do in a v2 UI built on top of indicatif or a similar library rather than the current v2 UI

fast-nail-55400 · Answer

the swim lanes really just require a description of what a particular rule is doing

fast-nail-55400 · Answer

and at a high level the user invokes one or more goals and then Pants figures out particular tasks to do in furtherance of those goals

witty-crayon-22786 · Answer

and a start and end presumably

hundreds-breakfast-49010 · Answer

I m right in the middle of reading the indicatif docs and seeing if we can make it replicate the current v2 UI experience straightforwardly

fast-nail-55400 · Answer

yes and some rules may be able to predict their end and show progress fetchers while others may not be able to and just describe what they do

hundreds-breakfast-49010 · Answer

it definitely looks like this lib has an option for leaving a line on the screen once a task is complete

fast-nail-55400 · Answer

in some sense you could have rules implement two type classes Description and Progress

fast-nail-55400 · Answer

as for how to do that in a Pythonic way someone else might need to weigh in

witty-crayon-22786 · Answer

although in practice what implements things are rust `graph Node`s exactly one of which represents a python rule

witty-crayon-22786 · Answer

but yes

hundreds-breakfast-49010 · Answer

we can always add more annotations on a rule although that doesn t get us the interactivity we need

hundreds-breakfast-49010 · Answer

and we can always add more methods to the `Node` trait in rust

fast-nail-55400 · Answer

well you could also add function attributes that are invoked by the engine

witty-crayon-22786 · Answer

< hundreds breakfast 49010> so i think that it is probably totally fine for python rules to never implement Progress

witty-crayon-22786 · Answer

only intrinsics

hundreds-breakfast-49010 · Answer

that makes sense to me

fast-nail-55400 · Answer

gt so i think that it is probably totally fine for python rules to never implement Progress that makes sense as well simplifies rules written in Python

fast-nail-55400 · Answer

an interesting idea would be if the rule itself doesn t have to implement the type class itself since type classes are usually implemented separately from the underlying class can the engine resolve a request to find a rule that returns a Description type class given the type of the rule

fast-nail-55400 · Answer

like a meta rule

fast-nail-55400 · Answer

but that might be too complex for now

fast-nail-55400 · Answer

higher kinded types for Pants

witty-crayon-22786 · Answer

whoa there

witty-crayon-22786 · Answer

smiley

fast-nail-55400 · Answer

although my FP fu is such that I probably am misusing the HKT reference

witty-crayon-22786 · Answer

the existing pattern is just for `Node` to have methods that return an Option don t need to get into meta rules heh

witty-crayon-22786 · Answer

witty-crayon-22786 · Answer

there are only 8 or 9 total `Node` types in the engine currently

witty-crayon-22786 · Answer

so super flexible extension isn t a necessity there

hundreds-breakfast-49010 · Answer

rust is great for a lot of things but not so much for the real esoteric FP stuff

witty-crayon-22786 · Answer

witty-crayon-22786 · Answer

where NodeKey Task is the rust representation of a python rule

hundreds-breakfast-49010 · Answer

I don t think the current `Node` abstraction is a barrier to implementing any of these ideas the harder part is what python APIs to we want to build

fast-nail-55400 · Answer

yeah and I just threw the HKT stuff out half jokingly we should just adopt enough FP as makes sense and no further too much FP can be too much

hundreds-father-404 · Answer

gt too much FP can be too much Especially too much FP mixed with dozens of Pants abstractions We already have a lot of concepts for plugin authors

witty-crayon-22786 · Answer

The best API is no API =

hundreds-breakfast-49010 · Answer

something that came up in conversation with < hundreds father 404> over the weekend is that we currently have a couple of different notions of how to display a representation of a rule that we use slightly differently in different places

hundreds-breakfast-49010 · Answer

<https github com pantsbuild pants issues 7509 issuecomment 565650068> was my attempt at trying to make sense of them last year but I think some of this is out of date now