Windows build fails due to unconditional Unix-only daemonization dependency (daemonize)

Summary

Building spacebot on Windows fails because the crate unconditionally depends on daemonize and compiles Unix-specific daemon code.

This is not caused by open (even though Cargo output may show Compiling open v5.3.3 nearby). The failing crate is daemonize.

Environment

• OS: Windows (observed on Windows 11)
• Rust: stable (edition 2024 project)

Error (excerpt)

Cargo fails while compiling daemonize-0.5.0 with errors like:

• could not find unix in os
• missing libc::uid_t, gid_t, umask, fork, setsid, etc. on Windows

Why this happens

spacebot declares daemonize = "0.5" as a normal dependency:

• Cargo.toml:86

and calls it from the daemon module:

• src/daemon.rs:87
• src/daemon.rs:107
• src/main.rs:184

The daemon module also uses Unix-only APIs directly (e.g. std::os::unix::net::UnixStream in src/daemon.rs:71), so Windows builds need cfg(unix) gating regardless of the daemonize dependency.

Expected behavior

• Windows builds should either:
  1. compile successfully with daemonization functionality disabled / unsupported.

Suggested fix

• Move Unix-only deps behind target-specific dependencies, e.g.:
  • daemonize
  • likely libc if only used for daemon code
• Gate Unix daemon implementation with #[cfg(unix)]
• Provide Windows stubs / error messages for daemon commands (e.g. "daemon mode is not supported on Windows yet")

Notes

Cargo output may mention Compiling open v5.3.3, but Cargo.lock shows open does not depend on daemonize; this appears to be parallel build output interleaving.

Start with the dependency declaration at Cargo.toml:86 and the Unix-specific references in src/daemon.rs:71, 87, and 107, plus the call site in src/main.rs:184. Run a Windows build to confirm the failure, then verify that Unix daemonization remains available while Windows builds compile and daemon commands report unsupported functionality.