Better name?
Closed this issue · 8 comments
The project originally (as the name implies...) only supported env_logger specific set up for tests. With the addition of tracing support the name is no longer a great fit and to the point that it is actively confusing/misleading. I am not a fan of any legacy cruft and an unsuitable name falls in that category.
As such, I am open to renaming the project if there is a good suggestion for an alternative name. If you have a good suggestion please leave a comment. Cheers!
Hello 👋 thanks for making this crate!
What are your thoughts on tracing-log-test or tracing-env-log-test?
Thanks for your suggestions! I think that ideally we'd not have references to specific crates in the name. Otherwise we may run into a similar problem down the line if something new comes along. What do you think about test-log?
Another idea is to change the repository to the name you suggest, then split the features for slog and trace into two separate crates (with a workspace) and publish them under specific names.
Hm, interesting thought. I think that impedes usability, though: one can't easily have tracing and log enabled at the same time. You'd now have to nest #[test] attributes, which, while supported, is much less ergonomic than setting a feature.
Could you explain for me what issues prevent tracing and log from being enabled at the same time?
Conceptually they work together fine. From my perspective it doesn't make sense to enable both by default unconditionally because they each pull in vastly different dependencies. That also means that those dependencies need to be built which increases build time. Not only that, because of the way procedural macros work, clients have to specify said dependencies in their crate. (I think we can work around the latter constraint by introducing an intermediate crate, and I am considering doing that for convenience reasons, but I don't think that this will fundamentally change my stance on the matter and it certainly does not eliminate the other concerns)
Kind of on that note, I actually entertained the thought of making the crate even more "generic" (and, in a way, a kitchen sink): it could end up being called test-init and then also sport support for, say, async functions via tokio, for example. I really dislike having to manually import tokio and nest test attributes whenever I test an async function (e.g., here).
The main reason being that this crate's sole purpose is basically to make various test initialization steps more convenient, by providing them behind an attribute, controlled more or less centrally through the use of features. That would basically be the opposite direction of what you suggested, @seanpianka, but I think given that usability is basically the main criteria, it's at least a somewhat logical step.
Does anybody have any comments on that thought?
I have renamed the crate to test-log. I believe that it strikes a good compromise on all axes.