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.
ok, I'm hooked - how is setting an env var in the current process unsafe? My gut says it's not unsafe in a memory-ownership sense, but rather in a race condition sense?
whatever the issue is, "setting an env var is unsafe" is so interesting to me that I'm now craving a blog post explaining this
Ironically a project that hasn't been changed in a while "unmaintained" is a good candidate for bumping to v1, while a project with new breaking commits every day is a bad candidate.
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.
How much maintenance could you possibly need to load secrets from .env into the environment.