I suggest that the error be kept as is.

Reason

The only place where the error can occur is the dotenvy::var function that @allan2 mentioned. This is a thin wrapper around dotenv().ok() and std::env::var, which is probably why the author chose to emit the same error.

The forum post's conclusion about the underlying VarError seems appropriate for this crate. It is the expected behaviour of the standard library's var function, which this crate just wraps.

Also, if you are not needing that information (maybe because you know the environment variable you were interested), it would make the error bigger and more expensive to create than necessary.

Solution

Improving the documentation around this topic might be the best course of action. For example showing how to wrap the error using anyhow::Context, mapping it onto a custom error type, or adding an expect message as in @allan2's example:

dotenvy::var("FOO").expect("FOO not found");  // panicked at FOO not found: EnvVar(NotPresent)

Alternative

Alternatively, or perhaps additionally, a more detailed error could be put behind a Cargo feature. That way users could opt in to using an error similar to PR #15.

Sidenote

Interestingly the dotenv! macro uses the name of the missing variable in its error message. Again, it mimics the behviour of the standard library: env!.

The dotenvy::var function only ever returns Error::EnvVar. The fact that it calls dotenv().ok is unrelated to its behaviour when it comes to checking a variable exists.

v0.16 now includes the path to the env file in the error message.