Trait DotEnvParserConfig 

pub trait DotEnvParserConfig: Parser {
    // Provided methods
    fn additional_dotenv_files(&self) -> Option<Vec<PathBuf>> { ... }
    fn dotenv_can_override(&self) -> bool { ... }
}

automatic dotenv processing configuration

Available configuration for the DotEnvParser trait.

Default implementations are what you’d expect. Use this derive macro for typical use cases.

Order Matters!

Environment variables are processed/set in this order:

1. Preexisting variables already defined in environment.
2. The .env file, if present.
3. additional_dotenv_files supplied file(s) (sequentially, as supplied).

Keep in mind:

• Depending on dotenv_can_override, environment variable values may be the first or last processed/set.
• additional_dotenv_files should be supplied in the order to be processed.

Examples

#[derive(DotEnvDefault)]
struct Args {}

#[entrypoint::entrypoint]
fn main(args: Args) -> anyhow::Result<()> {
    // .env variables should now be in the environment
    for (key, value) in std::env::vars() {
        println!("{key}: {value}");
    }
}

Provided Methods

fn additional_dotenv_files(&self) -> Option<Vec<PathBuf>>

additional dotenv files to process

Default behavior is to only use .env (i.e. no additional files). This preserves the stock/default dotenvy behavior.

Order Matters!

Examples

struct Args {
    /// allow user to pass in additional env files
    #[arg(long)]
    user_dotenv: Option<std::path::PathBuf>,
}

impl entrypoint::DotEnvParserConfig for Args {
    fn additional_dotenv_files(&self) -> Option<Vec<std::path::PathBuf>> {
        self.user_dotenv.clone().map(|p| vec![p])
    }
}

fn dotenv_can_override(&self) -> bool

whether successive dotenv files can override already defined environment variables

Default behavior is to not override. This preserves the stock/default dotenvy behavior.

Order Matters!

Examples

impl entrypoint::DotEnvParserConfig for Args {
    fn dotenv_can_override(&self) -> bool { true }
}

Dyn Compatibility

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety", so this trait is not object safe.

Implementors