Refactor the logging component to a tracing component.

[hdevalence]

Will resolve #149 when complete.

Some questions:

1. How do I determine whether ANSI should be used?
2. Should the tracing settings respect RUST_LOG?

I didn't update the crate list in the README.

[hawkw]

I commented on a few things. I'm not sure what @tarcieri thinks is best for abscissa in particular, so none of my feedback should be considered blocking :)

[hawkw]

Looking at the log code that was removed in this PR, it looks like ansi colors were always used (but I may be misreading it?)

[tarcieri]

A lot of the color support regressed when I switched from term to termcolor (#47). I posted some up-to-date thoughts on it in this comment:

#154 (comment)

[hawkw]

It looks like the removed logging code always used UTC timestamps. Should we configure tracing's timestamps to also use UTC?

[tarcieri]

I'm fine with using the system timezone (which for all of my servers is UTC) if that's the default.

[tarcieri]

How do I determine whether ANSI should be used?

There's an Application::term_colors method you can source that info from.

Also as of #148 the atty crate is a hard dependency. It might make sense (but is certainly not required, just food for thought) to disable colors if no TTY is detected.

Should the tracing settings respect RUST_LOG?

It wasn't respected before, but I think it'd be a good idea. I've had people try to use it who were confused when it didn't work.

[hdevalence]

It might make sense (but is certainly not required, just food for thought) to disable colors if no TTY is detected.

If the tracing component uses Application::term_colors, does it make sense to also do TTY checking there, or would that logic (if it existed) be better in the term_colors function itself?

[tarcieri]

It'd be better if the term_colors method did it, so it also affects the color settings for the terminal component and color-backtraces

[hdevalence]

I'm not sure which of the discussions above are "resolved", but I think that the remaining things are: 1) correct use of Application::term_colors and 2) overriding config-based filters with the value of RUST_LOG?

[hdevalence]

I know how to construct a filter based on RUST_LOG using from_default_env via https://docs.rs/tracing-subscriber/0.2.0-alpha.1/tracing_subscriber/filter/struct.EnvFilter.html#method.from_default_env , but I don't know how to have that override a filter directive -- it looks like using https://docs.rs/tracing-subscriber/0.2.0-alpha.1/tracing_subscriber/filter/struct.EnvFilter.html#method.add_directive will override the env variable rather than the other way around.

[tarcieri]

@hdevalence yup, sounds good!

[tarcieri]

Re: RUST_LOG, it doesn't work currently, so if nothing else it won't be a regression if you want to save it for a followup PR (or perhaps I can take a look). It's just a nice-to-have.

[hdevalence]

Okay, this is blocking ZcashFoundation/zebra#108 so I would prefer to fix up the RUST_LOG stuff later if that's OK.

[tony-iqlusion]

@hdevalence if you're done it looks good to me

[hdevalence]

Yep!