-
-
Notifications
You must be signed in to change notification settings - Fork 636
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Call for proposals: improved @rule display #7509
Comments
I definitely think the wildcard is most friendly. But with an eye to only py3.6+ support:
Including the inner requests at all seems noisy no matter how this is done. To find the problem rule I probably just want the file / signature no matter the language the rule is implemented in. |
#7024 has some / a lot of these types of changes already implemented, I should get back to that or just merge it, oops. |
Would be good to wait for the discussion here to die out a bit first. Adding newlines in rulegraph rendering might be fine, but would not work for CLI rulegraph construction errors... so at least two cases probably. But if the rendering for "introspection/visualization and rule-graph construction failures" ends up concise enough, maybe it doesn't need newlines...? unclear. |
I like the wildcard proposal too! |
Yes, however, I don't think we should be using the same display for the rule graph and CLI anyway -- I feel like all that information is necessary to describe why each node has arrows to all its neighbors and that PR focuses a lot on e.g. coloration of node by type, which is a really reasonable and also orthogonal line of investigation. |
I definitely want the return type to be present. Accordingly, @jsirois's modified wildcard sounds good to me. |
Two things!
|
Assigning to @gshuflin who is looking into this. |
Note that this is also relevant in various error messages, such as rule graph errors. This is pretty unreadable:
|
Since this issue was created, we've introduced the concept of named rules, with the idea that giving an |
Hmm, I think that in error messages whose audience is rule authors (like the one I pasted above) we probably want to use the signature. I think we can distinguish between the static stringification of a rule function (e.g., as used during rule resolution, when there is no actual invocation yet), and the dynamic stringification of a rule function invocation, which can fall back to the former, but can optionally be nicer, using the named rule thing, plus whatever logic we come up with for displaying specific details of the invocation argument values. |
wanted to put down my thoughts about a general unified paradigm for displaying Right now the rust engine code requires that an implementer of the I've also been working on adding support for named rules, and creating a The error messages in rule graph errors are coming from prints in Here's my proposal for what to change: -We'll leave all rust auto-implementations of debug alone. this is consistent -The display impl for an -The display impl for nodes that are not -We will try to make sure that user-facing error messages always use the -We will create a new notion of "display info", which we implement by adding a -Display info's will be used in two places: naming workunit outputs reported to -The rule graph vizulation should use the display output of rules. |
One more idea - "Display info" is a bad name because it sounds too much like "Display", we should call that concept something different and name the method that provides it something different as well. |
+1
+1
I mentioned this briefly here: #8592 (comment) ... IMO, there are a few very cheap, very high value places to add names for intrinsic
So, to be explicit (because this very useful comment is on this ticket rather than on #7907): this issue was originally more about the rendering of rules in the
Yep... makes sense. I thought you had already done that in #8592 though...?
Yep, makes sense.
Yep. |
I added a notion of a display info in that commit; what I'm talking about is making that part of the |
…8828) This is a first chunk of work addressing some of the issues in #7509 . In this commit, we introduce the notion of a user-facing-name defined on a Node (distinct from the Display implementation), define one automatically for ExecuteProcessRequests (in a fairly naive way - we might want to display more information about EPRs later), and use it in the live-updating swim lanes display of the v2 console UI.
#8998 implements the majority of this ticket. There are some possible followups I punted on:
|
This closes #7509 to improve graph error messages and the graph visualization. This makes the following improvements: * Represent rules as Python 3 type signatures: `foo(A, B) -> C` * Intrinsics: `<intrinsic>(A) -> B` * Represent `Get`s as `Get[A](B)` * Prefix the `Rule` str with `@rule` or `@goal_rule`. * This allows us to group the `gets=` kwarg with the rule signature. We could stop outputting `gets`, but this is often a very useful thing to display when debugging graph issues. * Use the full module name for the rule function. * Better grepping for the rule. * Disambiguates between `isort.fmt` and `black.fmt`. * Includes the line number for rules. * Allows us to jump to line. * Mirrors other tools like Pytest. * Use `, ` to join Params, rather than `+`. * We use `, ` everywhere else. * Easier on the eye because more whitespace. * Reword `"Was not usable by any other @rule."` * This message suggests that no rules consume the rule, which isn't the issue. * Instead, the issue is that the rule is not _reachable_. * Point out that this happens when the rule is shadowed or no rules can produce the params. ### Before ``` (A, [B], [Get(X, Y)], a_from_b_noop()) ``` ### After ``` @rule(pants_test.engine.rules:84:a_from_b_noop(B) -> A, gets=[Get[X](Y)]) ``` There are still some possible followups, tracked by #7509 (comment).
from @stuhood in #7509 (comment):
I totally agree -- #7024 has decided to punt on that for now, only because the method used there to display |
Here is an old branch that demonstrates doing it (while breaking a bunch of tests, probably): master...twitter:stuhood/move-dependencykey-info-to-edges |
Currently, the
Display
impl for@rule
s results in:... which does not obviously represent a python function. We should refactor this so that these are more recognizable (ideally without losing any information). Ideally this would be a one-liner.
A few potential candidates:
Foo
from aBar
to provide a param, you'd haveFoo
in the signature andBar
in the body).The text was updated successfully, but these errors were encountered: