Repository navigation
structured notification system is getting unwieldy #1875
Description
Activity
We thought about migrating most of the notifications to a standard logging framework, but then there is the idea to move to something external to replace our progress bars, so perhaps a context which can be passed around which is a conduit to a UX thread dealing with all of that might make sense.
Reacted by TrevorAnother design requirement: structured programmatic output for use from visual code and other tools.
I'm thinking of bolting a structured encoding - e.g.. protobuf- onto stdout; ok maybe protobuf is a bad choice and YAML or something less demanding of clean 8-bit channels would be better, though, waggles hand, I've been around that before with subunit and honestly biting the bullet and making it truely 8-bit clean wasn't that hard and chased bugs out of the system.I think this issue can be closed as resolved given the following advancements:
- The removal of the notification enums: Remove more Notification variants (part 3) #4510
- The use of
indicatiffor progress reporting: Refactor the DownloadTracker in favor ofindicatif#4426 - The use of
tracing_subscriberfor logging: chore(dist/features): shiptracingand friends by default #3803
Describe the problem you are trying to solve
We're having to generate user feedback from many narrow places in the code - such as spin-loops around rename() syscalls to deal with virus scanners - and the notification system as it currently all hooks together is quite unwieldy.
Describe the solution you'd like
I haven't thought this far ahead yet. I will. Perhaps a 'context' object of some sort that we make systematically available. I'd like to avoid creating overly strong coupling in the system. And I'd like it to be designed work with an eventual highly concurrent build where multiple tars are downloading and unpacking all at once with 4 or 5 lines of progress bar showing at once.
Notes