June 08, 2018
On Friday, 8 June 2018 at 16:11:27 UTC, Basile B. wrote:
> While this look okay please in the initial PR don't forget to add code to deactivate colors when DUB will be piped.

Sure, I won't forget about that. On Linux (and I guess also MacOS) it should be enough to check if stdout is a tty (isatty() from C std) or not, while I don't know how that could be done on Windows. Do you have any idea?
June 08, 2018
On Friday, 8 June 2018 at 16:20:12 UTC, gdelazzari wrote:
> On Friday, 8 June 2018 at 16:11:27 UTC, Basile B. wrote:
>> While this look okay please in the initial PR don't forget to add code to deactivate colors when DUB will be piped.
>
> Sure, I won't forget about that. On Linux (and I guess also MacOS) it should be enough to check if stdout is a tty (isatty() from C std) or not, while I don't know how that could be done on Windows. Do you have any idea?

Certainly. look at how DMD does that ;)
June 08, 2018
On Friday, 8 June 2018 at 16:33:29 UTC, Basile B. wrote:
> On Friday, 8 June 2018 at 16:20:12 UTC, gdelazzari wrote:
>> On Friday, 8 June 2018 at 16:11:27 UTC, Basile B. wrote:
>>> While this look okay please in the initial PR don't forget to add code to deactivate colors when DUB will be piped.
>>
>> Sure, I won't forget about that. On Linux (and I guess also MacOS) it should be enough to check if stdout is a tty (isatty() from C std) or not, while I don't know how that could be done on Windows. Do you have any idea?
>
> Certainly. look at how DMD does that ;)

I had a look at it, really helpful, thanks!
June 08, 2018
On 2018-06-08 15:38, Steven Schveighoffer wrote:

> Looks excellent! Two thumbs up from me. Is it cross-platform?
> 
> Note on some platforms (ahem, Macos) the background is white, so this should be correctly colored for that possibility.

On macOS everyone should use iTerm :), which has a dark background by default.

-- 
/Jacob Carlborg
June 08, 2018
On 2018-06-08 15:38, Steven Schveighoffer wrote:

> Note on some platforms (ahem, Macos) the background is white, so this should be correctly colored for that possibility.

I would assume that the theme of the terminal is setup so that all colors (except white and black) work together with the background color of the theme.

-- 
/Jacob Carlborg
June 08, 2018
On 6/8/18 4:35 PM, Jacob Carlborg wrote:
> On 2018-06-08 15:38, Steven Schveighoffer wrote:
> 
>> Looks excellent! Two thumbs up from me. Is it cross-platform?
>>
>> Note on some platforms (ahem, Macos) the background is white, so this should be correctly colored for that possibility.
> 
> On macOS everyone should use iTerm :), which has a dark background by default.
> 

I gotta say, I'm quite satisfied with the default console. I guess I'm not everyone :P

-Steve
June 08, 2018
On Friday, 8 June 2018 at 20:41:41 UTC, Jacob Carlborg wrote:
> On 2018-06-08 15:38, Steven Schveighoffer wrote:
>
>> Note on some platforms (ahem, Macos) the background is white, so this should be correctly colored for that possibility.
>
> I would assume that the theme of the terminal is setup so that all colors (except white and black) work together with the background color of the theme.

Actually, I was thinking about that too. In fact, what if a user is using a "classic" dark-background theme on macOS's terminal? Or another terminal which by default uses a dark background, like the one mentioned above? He would get all the colors and the text contrast messed up if I put a different color scheme for macOS only. The only valid option would be to check the background color of the terminal, but I don't think that's possible at all in a standardized way, unless someone can prove me wrong. That would be cool.
June 08, 2018
For anyone interested, I'm implementing everything in this branch of my fork.

https://github.com/gdelazzari/dub/tree/colored-output

Seems like I managed to cleanly substitute the logging module with a brand new one :P actually it's most copy-paste with changes to allow colored output, but yeah. I also "imported" d-colorize (by copying all its file in Dub's codebase - to avoid having a Dub package dependency on Dub itself).

This is the relevant part (the new logging module) if anyone wants to contribute with feedback or enhancements, since is some of the first D code I'm writing. It's still missing the no-TTY detection, but it's coming.

https://github.com/gdelazzari/dub/blob/colored-output/source/dub/logging.d
June 09, 2018
On Friday, 8 June 2018 at 13:35:36 UTC, gdelazzari wrote:
> Take a look at these screenshots:
>
> https://imgur.com/a/3RJyd6m
>

Very nice!

But related to your motivation for  this, I do really wish dub had far less output by default. For example, I don't need to be told over and over that each of my dependencies are up-to-date (or which version was chosen. I can always look at dub.selections.json or use --verbose if I need to check that.) And I dont need to be reminded about --force every time my build succeeds. Or for that matter, be told whether or not the compiler gave an error. If there are errors I can already see that they're there. Etc.
June 09, 2018
On Saturday, 9 June 2018 at 01:17:26 UTC, Nick Sabalausky wrote:
> On Friday, 8 June 2018 at 13:35:36 UTC, gdelazzari wrote:
>> Take a look at these screenshots:
>>
>> https://imgur.com/a/3RJyd6m
>>
>
> Very nice!
>
> But related to your motivation for  this, I do really wish dub had far less output by default. For example, I don't need to be told over and over that each of my dependencies are up-to-date (or which version was chosen. I can always look at dub.selections.json or use --verbose if I need to check that.) And I dont need to be reminded about --force every time my build succeeds. Or for that matter, be told whether or not the compiler gave an error. If there are errors I can already see that they're there. Etc.

While I mostly agree with you, I have to note that the reminder that you can use --force to force rebuilding everything only pops up when you "dub build" a package you just built, i.e. if you make some changes to the code and build, it won't show up in the output, as you can see in the first screenshot at my link. I think this is fine and makes sense, since a first time user may try to run "dub build" to rebuild the project without obtaining that effect, and that message will be useful to understand how to actually force rebuilding it if he/she really wants to.

I agree that the "Up-to-date" that pops up for every dependency is too verbose, and can definitely be removed. Also the "Failed, dub exited with code X" doesn't make a lot of sense as you said. Also it's not consistent since, if we keep that message, then why not also printing something like "Success, dub exited with code 0, build completed" at the end of a successful build? So yeah, agreed, it should go and doesn't carry more information that what you already know.

If anyone has other suggestions regarding Dub's output I'll be happy to take them, since I'm working on that anyway.