Does not build on wasm32

[kpeters-cbsi]

This is a dupe of fastly/cli#532 (comment), but the fix lies in either this package or gethostname

My Rust app uses v0.3.2 of tracing-bunyan-formatter and it fails to build for target wasm32-unknown-unknown:

Compiling gethostname v0.2.2
error[E0433]: failed to resolve: could not find `unix` in `os`
  --> /Users/cpete0624/.cargo/registry/src/github.com-1ecc6299db9ec823/gethostname-0.2.2/src/lib.rs:65:18
   |
65 |     use std::os::unix::ffi::OsStringExt;
   |                  ^^^^ could not find `unix` in `os`

error[E0432]: unresolved import `libc::_SC_HOST_NAME_MAX`
  --> /Users/cpete0624/.cargo/registry/src/github.com-1ecc6299db9ec823/gethostname-0.2.2/src/lib.rs:64:33
   |
64 |     use libc::{c_char, sysconf, _SC_HOST_NAME_MAX};
   |                                 ^^^^^^^^^^^^^^^^^ no `_SC_HOST_NAME_MAX` in the root

error[E0425]: cannot find function `gethostname` in crate `libc`
  --> /Users/cpete0624/.cargo/registry/src/github.com-1ecc6299db9ec823/gethostname-0.2.2/src/lib.rs:70:37
   |
70 |     let returncode = unsafe { libc::gethostname(buffer.as_mut_ptr() as *mut c_char, buffer.len()) };
   |                                     ^^^^^^^^^^^ not found in `libc`
   |
help: consider importing this function
   |
27 | use crate::gethostname;
   |

   Compiling tracing-log v0.1.2
error[E0599]: no function or associated item named `from_vec` found for struct `OsString` in the current scope
  --> /Users/cpete0624/.cargo/registry/src/github.com-1ecc6299db9ec823/gethostname-0.2.2/src/lib.rs:89:15
   |
89 |     OsString::from_vec(buffer)
   |               ^^^^^^^^ function or associated item not found in `OsString`
   |
   = help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope; perhaps add a `use` for it:
   |
27 | use std::os::wasi::ffi::OsStringExt;
   |

Some errors have detailed explanations: E0425, E0432, E0433, E0599.
For more information about an error, try `rustc --explain E0425`.
error: could not compile `gethostname` due to 4 previous errors
warning: build failed, waiting for other jobs to finish...
error: build failed.

[kailan]

There's a pull request on the gethostname crate that would resolve this: flausch/gethostname.rs#6

If that's released as 0.2.3 this crate should start compiling correctly.

[kpeters-cbsi]

That PR was rejected, so if it's to be fixed, the fix will have to be here.

[kailan]

Okay so that didn't work out as smoothly as expected.

The core issue here is that hostname is a required property of a bunyan log record. Environments without hostnames will need to provide something. So perhaps the solution to this is a parameter on BunyanFormattingLayer where an override hostname can be passed in, along with putting the gethostname dependency behind a default feature flag.

[LukeMathWalker]

I think that this can be accommodated without changing the public API of this crate.
The strategy I would suggest:

• introduce a hostname feature, enabled by default, which activates the dependency on gethostname and gates its usage;
• if hostname feature is not active, the constructor of the formatting layer must check that a hostname field has been passed along in the hashmap of default fields. If it hasn't, it panics. The panic message should be quite clear on the available options.

I'd be happy to review a PR in this direction.

[Bayernatoor]

I ran into this issue while working through Zero to Production, compilation failed as I am targeting "wasm32-unknown-unknown".

I've got 2 solutions in mind but the first will modify the API.

1. Add a new parameter hostname: Option<String> to BunyanFormattingLayer::new() which is used as HOSTNAME's value if hostname feature is not enabled. Otherwise user passes None to use gethostname() or can also pass a custom hostname if desired.

2. Add #[derive(Default) to the BunyanFormattingLayer struct and use the default <no_hostname> for field HOSTNAME if hostname feature is not enabled. This removes any panics, allows lib to build for any platform.

Edit: opened a PR for option 2: #39

I am very new to Rust but am eager to make this work without introducing breaking changes. Feedback is greatly appreciated :)

[Bakrog]

Just changing the hostname is not enough, the next error at wasm environment will be a panic when trying to get the process id and the usage of std::time::Instant.