dotenv 0.2.1

A `dotenv` implementation for Rust
docs.rs failed to build dotenv-0.2.1
Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
Visit the last successful build: dotenv-0.15.0

rust-dotenv

Achtung! This is a v0.* version! Expect bugs and issues all around. Submitting pull requests and issues is highly encouraged!

Quoting bkeepers/dotenv:

Storing configuration in the environment is one of the tenets of a twelve-factor app. Anything that is likely to change between deployment environments–such as resource handles for databases or credentials for external services–should be extracted from the code into environment variables.

This library is meant to be used on development or testing environments in which setting environment variables is not practical. It loads environment variables from a .env file, if available, and mashes those with the actual environment variables provided by the operative system.

Usage

The easiest and most common usage consists on calling dotenv::dotenv when the application starts, which will load environment variables from a file named .env located wherever your application binary is located; after that, you can just call the environment-related method you need as provided by std::os.

If you need finer control about the name of the file or its location, you can use the from_filename and from_path methods provided by the crate.

Examples

A .env file looks like this:

# a comment, will be ignored
REDIS_ADDRESS=localhost:6379
MEANING_OF_LIFE=42

You can optionally prefix each line with the word export, which will conveniently allow you to source the whole file on your shell.

A sample project using Dotenv would look like this:

extern crate dotenv;

use dotenv::dotenv;
use std::os::env;

fn main() {
    dotenv().ok();

    for (key, value) in env().into_iter() {
        println!("key: {}, value: {}", key, value)
    }
}

Issues

  • The way errors are implemented is not as nice as it could be. Now that FromError has landed, a better design for DotenvError and ParseError is possible.