temp-env

temp-env is a small Rust crate for setting environment variables temporarily while a closure runs, then restoring the previous state afterward. It is primarily useful for testing code whose behavior depends on environment variables, letting each test run with its own configuration without interfering with other tests.

It provides helpers to set one or many variables (or explicitly unset them), returning the closure’s value once it completes. Because environment variables are process-global, the crate serializes access with a lock and offers async variants for use with futures-based test code.

What You Get

• with_var to set or unset a single environment variable around a closure.
• with_vars to set or unset multiple variables at once, each optionally None to unset.
• Return-value passthrough so you can compute and capture a value inside the temporary environment.
• Automatic restoration of the prior environment state after the closure finishes.
• Optional async closure support via the async_closure feature for futures-based tests.

Common Use Cases

• Testing configuration loading code under different environment-variable values.
• Ensuring a test that mutates env vars does not leak state into other tests during cargo test.
• Exercising both the present and absent cases of an environment variable in isolated tests.

Under The Hood

Architecture - The entire crate lives in a single src/lib.rs (~540 lines including tests). The core pattern captures the current values of the target variables, applies the requested set/unset operations, runs the user’s closure, then restores the captured state in all exit paths. A parking_lot mutex serializes these mutations because the process environment is global shared state and concurrent test threads would otherwise race.

Tech Stack - Rust 2021 edition (MSRV 1.63) with a single runtime dependency on parking_lot for the lock, plus an optional futures dependency gated behind the async_closure feature. tokio is used only as a dev-dependency for async tests.

Code Quality - Despite its small size, the crate is thoroughly tested: the file contains an extensive in-module test suite covering single/multiple variables, unsetting, return values, panics, and async closures. Restoration is handled carefully so state is not leaked even if the closure panics, and the code is idiomatic and well documented.

API Design - The API is minimal and highly ergonomic — with_var(key, value, closure) and with_vars([...], closure) read almost like English, and returning the closure’s value keeps call sites concise. Using Option<&str> for the value elegantly expresses both setting and unsetting, so the getting-started boilerplate is essentially nil.