If we’re looking for random rust / rust-python bou...
# development
a
If we’re looking for random rust / rust-python boundary things, I’d really like
$ ./pants -ldebug cloc src/python/pants:version
to, where it currently prints:
Copy code
18:37:22 [DEBUG] engine::scheduler: Root Select(ExecuteProcessRequest(argv<HashableTypedCollection(Exactly(str))>=('/usr/bin/perl', 'bin/cloc/1.66/cloc', '--skip-uniqueness', '--ignored=ignored', '--list-file=input_files_list', '--report-file=report'), input_files<Exactly(Digest)>=Digest(fingerprint=bafbaf573c6f8f698926645eeba3b7ebfc5bd4d3ce1d05bf0333df475fd1b6ef, serialized_bytes_length=326), description<Exactly(str)>=cloc, env<HashableTypedCollection(Exactly(str))>=(), output_files<HashableTypedCollection(Exactly(str))>=('ignored', 'report'), output_directories<HashableTypedCollection(Exactly(str))>=(), timeout_seconds<Exactly(float or int)>=900, jdk_home<Exactly(str or NoneType)>=None), FallibleExecuteProcessResult) completed.
to instead print:
Copy code
18:37:22 [DEBUG] engine::scheduler: Root Select(ExecuteProcessRequest(description=cloc), FallibleExecuteProcessResult) completed.
trimming down the output from “a full dump of a repr of a python object” to “a targeted informational representation of a python object” This may tie in nicely with https://github.com/pantsbuild/pants/issues/7745 while also crossing the rust-python boundary
w
it might... but that also touches UX stuff. cc @red-balloon-89377
in general, we think that we are very likely to need "@rule author annotations to manually indicate that an @rule is worth rendering"
a
And relatedly, “This is how you should render me, if I’m worth rendering” 🙂
👌 1
w
@hundreds-breakfast-49010: which is related to the output of
./pants --no-v1 --v2 --v2-ui test $a_pure_python_test
, which @red-balloon-89377 worked on most recently
right, exactly
basically: we're using debug output for things that we hope to not use it for very long, because there are other plans
r
I think figuring out a principled way for rules to say that they should be rendered is a nice self-contained ticket that shouldn't require too much synchronization with the resto if the UI work
w
yea... @red-balloon-89377: if you have time to create that ticket, it would be very appreciated
it's also possible that Greg could work on the "remove interleaving" portion of the UX work...?
r
Sure thing :)
w
...maybe removing interleaving is a more obvious thing, because it would give us somewhere useful to render this new information?
r
That's a bit trickier, because it involves solving the "how do we want (or do we want at all) to stream test results
w
we don't plan to anytime soon.
r
Because it's really easy if we want to dump stdout at the end
But really hard if we need to sync on every test result
If we're going with option A for now (dump everything at the end), I prototyped some of that at the beginning of may, can certainly create another ticket
w
@red-balloon-89377: this is mostly already designed
i believe that that is all still relevant right now (ie, we're still punting on streaming test output.)
@hundreds-breakfast-49010: if you haven't read the v2 output HLD (3rd link above), you can get access to that google doc by joining
pants-devel@
r
Cool, I can create both of those tickets
I meant that I have a sketch of a solution for synchronization between Logger and Console in the UI
w
@red-balloon-89377: one of the above is still open as well... Maybe noving out the part that is still relevant into a new ticket
Ah, cool.
r
One issue created, with a part of #6004 cc\ @hundreds-breakfast-49010 https://github.com/pantsbuild/pants/issues/7906
I have opened https://github.com/pantsbuild/pants/issues/7907 to discuss the requirements of “how and when are @rules displayed”. I have some implementation ideas, but I want to be really sure that we agree on the requirements.