Support `no_std`

[TTWNO]

I'm writing a library that needs to be tested inside no_std environments. Since tracing, and tracing-subscriber do not inherently require std, it would be convenient to be able to use this crate to do so.

I've made some trivial changes, like importing alloc::{string::String, vec::Vec}, but the more important change is that I've switched std::env::var_os with core::option_env, which resolves an optional environment variable at compile time. I'm fine feature gating the std::env::var_os call behind an std feature if that is more acceptable for you.

Some things to consider:

• You may want to enable std_instead_of_alloc to identify types up front that can be easily used without std
• You may want an std flag to enable more features available via std that are not required for the base crate to work.

Thanks for all your work; I really enjoy this crate!

—Tait

[d-e-s-o]

Thanks for the pull request. For my understanding, what would be the motivation for running in a no_std environment? I get why a "production" crate wants to be no_std compatible, but this is a development crate, specifically designed to be used as a dev-dependency. I fail to see why one would want to have the associated constraints when running tests.

[TTWNO]

I understand this is meant as a dev-dep. The tests in my case need to be able to be run on the target machine, not just on any machine.

[d-e-s-o]

So you'd compile for the target, which doesn't have a Rust std environment, set the environment variables during compilation, copy the resulting binaries over, and then run the test? Is that the envisioned workflow?

I guess that seems like something we could conceivably support. And what is the intention of this pull request? Clearly it is not in any state to be merged. Are you asking for input? Do you want me to finish it?

[TTWNO]

So you'd compile for the target, which doesn't have a Rust std environment, set the environment variables during compilation, copy the resulting binaries over, and then run the test? Is that the envisioned workflow?

Yes.

Clearly it is not in any state to be merged.

Just missing a few clippy/fmt issues. Trivial fixup in the next few hours and it should be ready to go! :)

[TTWNO]

Looks like the clippy lint is failing on your main. Not sure exactly when this is from, but this is not due to a change in my PR.

[d-e-s-o]

Looks like the clippy lint is failing on your main. Not sure exactly when this is from, but this is not due to a change in my PR.

Probably due to a new Rust release. Will fix it up.

[TTWNO]

but we just use tracing-subscriber and env_logger as they are (i.e., with std enabled unconditionally). How is that going to satisfy your workflow?

tracing_subscriber has an std feature that you disable by default already, no problems there!

env_logger sort of fundamentally requires std; I have now made log depend on the std feature.

Since I only use trace this is no issue for me. Test added for trace

[d-e-s-o]

but we just use tracing-subscriber and env_logger as they are (i.e., with std enabled unconditionally). How is that going to satisfy your workflow?

tracing_subscriber has an std feature that you disable by default already, no problems there!

It works because env-filter enables std. Hence, there is an std environment available anyway. Then, what's the point of making this crate support a no_std environment if other dependencies are free to use std?

[dvdplm]

It's not uncommon that no_std crates want their test suites to run in no_std as well. Convincing maintainers to switch to using #![cfg_attr(not(test), no_std)] instead may or may not be possible and poses at the very least a papercut to adoption. Is it truly necessary for test-log to enable the env-filter feature or can it work without it?

[d-e-s-o]

It is what is evaluating RUST_LOG, so it seems pretty crucial to me.