https://pantsbuild.org/ logo
w

witty-crayon-22786

04/20/2020, 11:47 PM
in our case that might be "the completion of named rules turns into a log message"...? but you might have too many of them.
@fast-nail-55400: but to be clear: i agree. and that's been a user request.
just need to figure out what an appropriate unit is. and it may not be a process.
👍 1
h

hundreds-father-404

04/21/2020, 12:23 AM
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
w

witty-crayon-22786

04/21/2020, 12:24 AM
not sure whether the concept of "log levels" applies to named rules as well.
👍 1
h

hundreds-father-404

04/21/2020, 12:26 AM
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
Cc @hundreds-breakfast-49010
w

witty-crayon-22786

04/21/2020, 12:27 AM
it feels like there is an opportunity here to mostly discourage logging, and to lean in on named rules that have various levels.
...and which have a start and end.
this is not really that novel, honestly... the v1 API does it as well. it just takes that structure and nests it.
h

hundreds-father-404

04/21/2020, 12:29 AM
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..?
w

witty-crayon-22786

04/21/2020, 12:29 AM
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.
h

hundreds-breakfast-49010

04/21/2020, 12:30 AM
@witty-crayon-22786 benjy had talked about the desirability of dynamically setting information about a rule within the rule itself
👍 1
not as an annotation
@hundreds-father-404 I've been spending a lot of time looking at logging in both rust and python over the past few days
there's a lot of cruft in our abstractions, which I'm trying to get rid of
h

hundreds-father-404

04/21/2020, 12:31 AM
I agree. Annotations aren’t very helpful on their own. The interesting piece is the dynamic information
w

witty-crayon-22786

04/21/2020, 12:32 AM
h

hundreds-breakfast-49010

04/21/2020, 12:32 AM
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
w

witty-crayon-22786

04/21/2020, 12:32 AM
so
h

hundreds-breakfast-49010

04/21/2020, 12:32 AM
and yeah it's possible that the right thing to do is to discourage logging
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
w

witty-crayon-22786

04/21/2020, 12:33 AM
because as a reminder of where this Thread started: how do you have a UI for things that don't have starts and ends?
@hundreds-breakfast-49010: see @fast-nail-55400’s comment: https://pantsbuild.slack.com/archives/C0D7TNJHL/p1587426013252000
that doesn't necessarily mean log messages.
it means log messages currently, but only because we log exactly one place in the engine: in the test runner.
👍 1
h

hundreds-breakfast-49010

04/21/2020, 12:35 AM
@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
f

fast-nail-55400

04/21/2020, 12:35 AM
the swim lanes really just require a description of what a particular rule is doing
👍 2
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
w

witty-crayon-22786

04/21/2020, 12:36 AM
and a start and end, presumably.
h

hundreds-breakfast-49010

04/21/2020, 12:37 AM
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
f

fast-nail-55400

04/21/2020, 12:37 AM
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
h

hundreds-breakfast-49010

04/21/2020, 12:37 AM
it definitely looks like this lib has an option for leaving a line on the screen once a task is complete
f

fast-nail-55400

04/21/2020, 12:38 AM
in some sense, you could have rules implement two type classes: Description and Progress
👍 2
as for how to do that in a Pythonic way, someone else might need to weigh in
🐍 1
w

witty-crayon-22786

04/21/2020, 12:39 AM
(although in practice what implements things are rust `graph::Node`s, exactly one of which represents a python @rule)
but yes.
h

hundreds-breakfast-49010

04/21/2020, 12:39 AM
we can always add more annotations on a rule. although that doesn't get us the interactivity we need
and we can always add more methods to the
Node
trait in rust
f

fast-nail-55400

04/21/2020, 12:40 AM
well you could also add function attributes that are invoked by the engine
w

witty-crayon-22786

04/21/2020, 12:40 AM
@hundreds-breakfast-49010: so, i think that it is probably totally fine for python rules to never implement Progress.
only intrinsics.
h

hundreds-breakfast-49010

04/21/2020, 12:40 AM
that makes sense to me
f

fast-nail-55400

04/21/2020, 12:41 AM
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.
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?
like a meta-rule
but that might be too complex for now
“higher-kinded types for Pants”
w

witty-crayon-22786

04/21/2020, 12:45 AM
whoa there
😃
f

fast-nail-55400

04/21/2020, 12:45 AM
although my FP-fu is such that I probably am misusing the HKT reference
w

witty-crayon-22786

04/21/2020, 12:45 AM
the existing pattern is just for
Node
to have methods that return an Option. don't need to get into meta rules, heh
there are only 8 or 9 total
Node
types in the engine currently.
so super flexible extension isn't a necessity there
h

hundreds-breakfast-49010

04/21/2020, 12:47 AM
rust is great for a lot of things, but not so much for the real esoteric FP stuff
(where NodeKey::Task is the rust representation of a python @rule)
h

hundreds-breakfast-49010

04/21/2020, 12:48 AM
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
f

fast-nail-55400

04/21/2020, 12:51 AM
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.
💯 2
h

hundreds-father-404

04/21/2020, 12:54 AM
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.
w

witty-crayon-22786

04/21/2020, 12:56 AM
The best API is no API =)
❤️ 2
🔥 2
h

hundreds-breakfast-49010

04/21/2020, 12:57 AM
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
👍 1
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