Custom Logger

Relates to #162 and maybe even #95

Are there any plans to open up the Logger: https://github.com/Mpdreamz/bullseye/blob/master/Bullseye/Internal/Logger.cs#L12

More wondering out of my obsessive need to tinker rather than a real use case. In this case I would love to control how the tasks get ouput using something fancier then / to separate the chain.

If exceptions would flow to the logger in the future (#162) I would love to provide diagnosers for known exceptions though.

[Mpdreamz]

Personally I find the “back and forth” quite distracting

I agree, thank you for exploring this 👍

I’m not sure the benefit of less scrolling is worth the cost of the added complexity in the Bullseye API

It’s definitely something I can let go of at this stage, will reopen if it becomes something I run into often.

[adamralph]

@Mpdreamz I gave the arrows a try, but I can’t say I’m hugely convinced. Personally I find the “back and forth” quite distracting:

Regarding controlling the message prefix, I’m not sure it will really buy you much. Consider:

FooSolution/build: Starting...
.
.
.
(large amount of output from dotnet build)
.
.
.
FooSolution/build: Succeeded
FooSolution/test: Starting...
.
.
.
(large amount of output from dotnet test)
.
.
.
FooSolution/test: Succeeded

vs

=== FooSolution start ===    // your own log message
Bullseye/build: Starting...
.
.
.
(large amount of output from dotnet build)
.
.
.
Bullseye/build: Succeeded.
Bullseye/test: Starting...
.
.
.
(large amount of output from dotnet test)
.
.
.
Bullseye/test: Succeeded.
=== FooSolution end ===    // your own log message

Sure, you get “FooSolution” a little more often, but you’re going to have to do some scrolling in both cases. I’m not sure the benefit of less scrolling is worth the cost of the added complexity in the Bullseye API.

What do you think?