https://pantsbuild.org/ logo
#development
Title
# development
a

aloof-angle-91616

01/22/2019, 8:24 AM
had an EVEN BETTER IDEA in https://github.com/pantsbuild/pants/issues/7071#issuecomment-456309997 which can be summarized as "tee the stdout from zinc compiles to a file named `output.txt`":
Copy code
> ./pants --compile-zinc-workunit-output="+{'stdout': {'output.txt': ['COMPILE']}}" test ::
and the
stdout
corresponds to
workunit.output('stdout')
, but we can extend that to other output types to allow for non-hierarchical output labelling for an asynchronous v2 UI!
r

red-balloon-89377

01/22/2019, 12:00 PM
I really like the idea of teeing specific workunits’ outputs to specific files/streams(/sockets?), but I’m a bit lost as to how we would extend it to fit the V2 async model. I agree that file write synchronization is relatively easy to fix problem, but I find it hard to imagine the extensions of that command line, could you post an example?
a

aloof-angle-91616

01/23/2019, 9:08 AM
well it would be analogous to the
WorkUnitMessageType
i proposed in comments in the linked issue
Copy code
> ./pants --compile-zinc-workunit-output="+{'MESSAGE': {'message-output.txt': ['COMPILE']}, 'stdout': {'process-output.txt': ['COMPILE']}, 'stderr': {'error-log.txt': ['COMPILE']}, 'ERROR': {'error-log.txt': ['COMPILE']}}" test ::
MESSAGE
vs
ERROR
(`WorkUnitMessageType`s) can be an extended form of log message types like debug/warn/info/exception
r

red-balloon-89377

01/23/2019, 10:13 AM
Goootcha! Thanks for the explaination, I like the idea!
a

aloof-angle-91616

01/23/2019, 6:32 PM
i can totally dive in more and write code as necessary! am very excited about this but my opinions are highly malleable!