https://pantsbuild.org/ logo
Join Slack
Powered by
in our case that might be "the completion of named...
# development
w
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
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
not sure whether the concept of "log levels" applies to named rules as well.
👍 1
h
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
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
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
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
@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
I agree. Annotations aren’t very helpful on their own. The interesting piece is the dynamic information
w
h
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
so
h
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
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
@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
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
and a start and end, presumably.
h
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
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
it definitely looks like this lib has an option for leaving a line on the screen once a task is complete
f
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
(although in practice what implements things are rust `graph::Node`s, exactly one of which represents a python @rule)
but yes.
h
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
well you could also add function attributes that are invoked by the engine
w
@hundreds-breakfast-49010: so, i think that it is probably totally fine for python rules to never implement Progress.
only intrinsics.
h
that makes sense to me
f
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
whoa there
😃
f
although my FP-fu is such that I probably am misusing the HKT reference
w
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
rust is great for a lot of things, but not so much for the real esoteric FP stuff
w
(where NodeKey::Task is the rust representation of a python @rule)
h
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
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
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
The best API is no API =)
❤️ 2
🔥 2
h
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
Open in Slack
PreviousNext
Powered by