Automatically include dependencies

[tamird]

• Move macros to a new test-log-macros crate.
• Export env_logger and tracing_subscriber from the test-log crate.
• Macros emit test_log::{env_logger,tracing_subscriber} references.

Removes the need for users to explicitly depend on additional crates.

Fixes #36.

[tamird]

Needed some elbow grease to get minimum versions working, but this is green now.

[d-e-s-o]

Very cool! Will take a closer look later this week.

[d-e-s-o]

Overall this looks good. I'd prefer we move the macros stuff into macros/ in the workspace root instead of crates/test-log-macros (crate name is fine, though). Can you please revert format changes that snug in as part of the lib.rs code move?
I think we are going to have to adjust the publish workflow to accommodate, but I guess I can take care of that.

The other thing is, with this change users loose the ability to indirectly control additional features of, say, tracing-subscriber. E.g., earlier a project could add

tracing-subscriber = {version = "0.3.17", default-features = false, features = ["ansi", "env-filter", "fmt"]}

and would get colored traces. This no longer works. I don't think it's a deal breaker, but it kind of sucks. But I guess the set of features this applies to is limited, and given that env_logger supports colored output now as well, we may as well expose a color feature ourselves. But that can come later.

[d-e-s-o]

Can we remove the empty section?

[tamird]

Done.

[d-e-s-o]

Let's use this stuff instead: https://github.com/d-e-s-o/websocket-util/blob/47d11990cf0a3c03ab9097c4c85d331dff60e92d/Cargo.toml#L35-L38

[tamird]

Done.

[tamird]

Overall this looks good. I'd prefer we move the macros stuff into macros/ in the workspace root instead of crates/test-log-macros (crate name is fine, though).

I had put it in crates so that the workspace specification can use a glob:

[workspace]
members = ["crates/*"]

otherwise this list needs an update any time a new crate is added to the workspace. Let me know if you insist.

Can you please revert format changes that snug in as part of the lib.rs code move?

Done. That snuck in because I ran cargo fmt on stable, which doesn't know about some of the options used in this project.

I think we are going to have to adjust the publish workflow to accommodate, but I guess I can take care of that.

The other thing is, with this change users loose the ability to indirectly control additional features of, say, tracing-subscriber. E.g., earlier a project could add

tracing-subscriber = {version = "0.3.17", default-features = false, features = ["ansi", "env-filter", "fmt"]}

and would get colored traces. This no longer works. I don't think it's a deal breaker, but it kind of sucks. But I guess the set of features this applies to is limited, and given that env_logger supports colored output now as well, we may as well expose a color feature ourselves. But that can come later.

I've changed the optional dependencies version specs to use >= so that the use case you describe still works. See the comment I added.

[d-e-s-o]

I had put it in crates so that the workspace specification can use a glob:

[workspace]
members = ["crates/*"]

otherwise this list needs an update any time a new crate is added to the workspace. Let me know if you insist.

I think it's fine to update the list when a new member is added and would go so far to say that listing each explicitly is, well, more explicit. I just can't get myself to liking the crates/ container directory, though I acknowledge that it's subjective and that a bunch of projects use that.

I've changed the optional dependencies version specs to use >= so that the use case you describe still works. See the comment I added.

To be honest, it seems to work with and without your changes now. No idea what I did or didn't do yesterday. Regarding your change: Will this mean that if tracing-subscriber releases an incompatible 0.4 that everything may break? If so, I'd prefer we stick to the default semver requirements to be on the safe side. Sorry for the confusion.

[tamird]

I had put it in crates so that the workspace specification can use a glob:

[workspace]
members = ["crates/*"]

otherwise this list needs an update any time a new crate is added to the workspace. Let me know if you insist.

I think it's fine to update the list when a new member is added and would go so far to say that listing each explicitly is, well, more explicit. I just can't get myself to liking the crates/ container directory, though I acknowledge that it's subjective and that a bunch of projects use that.

Done.

I've changed the optional dependencies version specs to use >= so that the use case you describe still works. See the comment I added.

To be honest, it seems to work with and without your changes now. No idea what I did or didn't do yesterday. Regarding your change: Will this mean that if tracing-subscriber releases an incompatible 0.4 that everything may break? If so, I'd prefer we stick to the default semver requirements to be on the safe side. Sorry for the confusion.

Done.