Remove windows-sys from home

[Jake-Shadle]

What does this PR try to resolve?

This replaces the windows specific implementation of home with the one from std::env::home_dir as it logically matches, allowing the removal of the windows-sys dependency.

How to test and review this PR?

Run the test_with_without unit test to confirm it works the same. home doesn't contain any tests itself as #16918 (comment) requested I remove the target specific code, presumably windows CI will break if the std implementation is different in some way.

[rustbot]

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @ehuss, @epage, @weihanglo
• @ehuss, @epage, @weihanglo expanded to ehuss, epage, weihanglo
• Random selection from ehuss, epage, weihanglo

[epage]

Isn't the MSRV high enough now that we can just drop our own implementations and instead use the std versions?

[Jake-Shadle]

The implementations are slightly different, SHGetKnownFolderPath vs GetUserProfileDirectoryW, unsure if that matters whatsoever for this use case, but can definitely just remove all of the extra code and call std if you want that.

[epage]

So long as they have the same behavior, which I believe was the intention of the recent std changes, we should be good

[Jake-Shadle]

Ok, I just removed the windows implementation entirely, but kept the windows specific unit test just to confirm that the std implementation behavior matches, which I confirmed under wine.

[epage]

Can we remove platform-specific logic completely?

Could you have your commits reflect how this should be reviewed and merged, rather than how it was developed?

[ChrisDenton]

Would it be worth deprecating home::home_dir now? If the only reason someone is using the home crate is because of that then they probably should switch to std::env::home_dir, no?

[epage]

I think I'd hold off on deprecation for now since depending on home@0.5 could be nice for people with an extended MSRV.

[arlosi]

Do we need to hold off on making a change here since older versions of the Rust toolchain would still use the incorrect behavior on Windows when using this crate?

MSRV-aware cargo will prevent it, but that's Cargo 1.84 (2025-01-09)+. which only gets us one version older than the 1.85 change that fixed the std function.

The other option here is to bump the minor version and consider this a breaking change.

[epage]

Do we need to hold off on making a change here since older versions of the Rust toolchain would still use the incorrect behavior on Windows when using this crate?

homes MSRV right now is 1.92. Without --ignore-rust-version, Cargo will fail to build home on anything older. So if we make this change, the users have to be explicitly opting in to an unsupported state to have a problem.

[arlosi]

Given that this won't build on versions of the rust toolchain that are older than the change to fix std::env::home_dir in std, this seems safe to merge.

View changes since this review

[arlosi]

The implementation here looks good, but I'd like to get the docs updated before merging.

View changes since this review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[Jake-Shadle]

@rustbot ready