menv Crate Announcement

I recently published the menv crate. It’s an expanded version of a snippet I’ve been pasting across my personal projects for months now, and is now available dual licensed under the MIT and Apache 2.0 licenses.

It provides a require_envs! macro, where you’re meant to list out all of the environment variables used by a binary, and it generates a getter function for each which delegates to FromStr, as well as a few extra utility functions: one for asserting the presence of all required vars, one for generating a help string for you to print, and one for checking if any of the listed vars are set.

mod env {
    menv::require_envs! {
        (assert_env_vars, any_set, gen_help);

        server_port, "FERRISCRAFT_USERS_PORT", u16,
        "FERRISCRAFT_USERS_PORT should be set to the desired server port";

        db_path, "FERRISCRAFT_USERS_DB", String,
        "FERRISCRAFT_USERS_DB should be set to the path to the users database";

        plugin_dir?, "XLANG_PLUGIN_DIR", String,
        "XLANG_PLUGIN_DIR, if set, overrides the directory that lccc looks for xlang plugins";
fn main() {
    if env::any_set() {
    } else {
        println!("# Environment Variables Help\n{}", env::gen_help());

Ideas for new features are welcome. Just file feature request issues on the menv source repository.

I’ve been using it to make server binaries, where I pretty much don’t care at all about having a nice CLI interface, and just need some way to provide keyword arguments. It produces better failure messages than env crates which insist on forcing environment variables through serde, by virtue of making you write a usage description for each environment variable you require with it.

This crate very much doesn’t pay attention to performance at all. It assumes that it’s okay to read the corresponding environment variable every time you call one of its generated getter functions. This behavior also makes it cooperate with std::env::set_var or setenv, for better or worse.

Writing Group

I was motivated to write this announcement by a writing group we formed in the RPLCS Discord. Other posts by our group are listed here: