Please reconsider endorsing `dirs` and deprecating `std::env::home_dir`

[Xaeroxe]

(Link for convenience: https://doc.rust-lang.org/std/env/fn.home_dir.html)

Recommending a user library in favor of the standard library is not an action without precedent.

However in this instance I think it's unwise. The author of dirs has made it clear they are not interested in providing the level and variety of support expected by users of the Rust std library.

What I, and I suspect most of the Rust community, would prefer is fixing the behavior of std::env::home_dir, and bringing it back from deprecation. Choosing to deprecate it and recommend another crate implies that someone could be relying on the current incorrect behavior of std::env::home_dir. Do we have any reason to believe someone is relying on that behavior? Is there room for disagreement as to what correct behavior is? My own review of the discussion surrounding this didn't seem to ask those questions and just deprecated it seemingly without questioning that.

If nothing else, at this point it seems wise to remove the recommendation of the dirs crate, even if rust-lang wants to leave the deprecation intact. EDIT: Removing the recommendation has been done.

[RalfJung]

The author of dirs has made it clear they are not interested in providing the level and variety of support expected by users of the Rust std library.

I do not see how the link here confirms that statement, it just shows the GH project index page?

[wareya]

The archive doesn't show it, but the dirs repository currently has the This repository has been archived by the owner. It is now read-only. marking on it.

[RalfJung]

I see. But that doesn't say anything about "providing the level and variety of support expected by users of the Rust std library".

[Xaeroxe]

@RalfJung I'm curious how marking the source repository read only could signal something other than "I'm not interested in maintaining this project anymore."

[RalfJung]

That was not your claim. You made a very specific claim for the motivation for them not wanting to maintain the project any more. I was asking why you think that "not interested providing the level and variety of support expected by users of the Rust std library" was the motivation.

You proved that they don't want to support this any more. You didn't prove your claim which said specifically why they don't want to support this any more.

[RalfJung]

To be clear, I am entirely on board with the goals of this issue -- to stop recommending an unmaintained crate.

I am just disputing a particular statement on the original post, which I believed and still believe to be unfounded.

[Xaeroxe]

"maintained", to me, is a subset of "the level and variety of support expected by users of the Rust std library."

EDIT: I never meant to imply they said as much, my initial comments are my own evaluation.

[RalfJung]

Most libraries are not maintained to the same standards as libstd. So I don't think "I don't want to maintain crate X any more" implies "I don't want to maintain crate X to the same standards as std".

But also, this is getting increasingly off-topic, so I will stop here.

[Xaeroxe]

To be clear, I am entirely on board with the goals of this issue -- to stop recommending an unmaintained crate.

Would opening a PR to remove the recommendation be appropriate at this time?

[RalfJung]

I'll defer that question to @rust-lang/libs -- dirs is unmaintained ("archived" on GH), should we change/remove the deprecation message that recommends using it?

[BurntSushi]

I think we should, at minimum, remove the recommendation for dirs. Probably just replacing it with text that says something like "use crates.io" would be fine. If we were compelled to provide a crate name, then probably home is the right answer. It's used by Cargo, for example. With that said, searching for "home directory" or "home dir" does have home show up in the first page of results.

It would be nice to un-deprecate and fix this, but this was certainly something that was considered. See:

• env::home_dir() should use SHGetKnownFolderPath() on windows. #28940 for an initial description of the issue with home_dir.
• home_dir incorrectly considers HOME environment variable on Windows #43321 is a duplicate of env::home_dir() should use SHGetKnownFolderPath() on windows. #28940.
• libstd trusts environment variables too much  #40320 is a tangential but related issue.
• Fix windows home dir implementation #46799 is pretty much exactly this issue, but ~2.5 years ago. Namely, we started by trying to fix home_dir, but as that issue discusses, there are issues doing that because it's a breaking change. Fix windows home dir implementation #46799 (comment) summarized our decision there and a possible path forward.
• Deprecate std::env::home_dir and fix incorrect documentation #51656 deprecated std::env::home_dir and recommended the dirs crate as an alternative.

Personally, I'd like to see a working home_dir function in std, but it sounds like fixing the current function is probably not a good path toward it. So perhaps a new function is warranted that does the "right" thing, whatever that is. (If home is good enough for Cargo and rustup, then maybe it is good enough for std?)