I agree with your general point, but for this specific functionality, I’ll point out that setting environment variables of the current process is unsafe. It took us a long time to realize it so the function wasn’t actually marked as unsafe until the Rust 2024 edition.

What this means in practice is that the call to invoke dotenv should also be marked as unsafe so that the invoker can ensure safety by placing it at the right place.

If no one is maintaining the crate, that won’t happen and someone might try to load environment variables at a bad time.

I find hilarious when people judge the quality of a repository by how many commits it has, as if 10.000 commits means the code is better.

The maintainers themselves give this warning in the repo's README, so even if it were maintained, it still wouldn't be production ready.

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

https://github.com/dotenv-rs/dotenv

Rust dev culture is allergic to any code that hasn't changed significantly in the last 3 months. Too easy, too stable.

On the other hand loading .env from the environment is critical (since you are usually passing secrets through .env). I wouldn't want to maintain that myself and not share it with a xxK other projects in case there is a vulnerability.

after testing that that very small fixed functionality you provide is correct

non

small "completed" well tested libraries being flagged as security issues due to being unmaintained seem to be starting to become an issue