home does not compile on wasm

[lorepozo]

Problem

The home crate does not build for wasm32-unknown-unknown. I encountered this through a transitive dependency from another crate.

Steps

$ cargo new bugreport
$ cd bugreport
$ echo 'home = "0.5"' >> Cargo.toml
$ cargo build --target wasm32-unknown-unknown

results in error:

error[E0425]: cannot find function `home_dir_inner` in the crate root
  --> .cargo/registry/src/index.crates.io-6f17d22bba15001f/home-0.5.5/src/env.rs:33:16
   |
33 |         crate::home_dir_inner()
   |                ^^^^^^^^^^^^^^ not found in the crate root

Possible Solution(s)

Home has no obvious place in wasm, so I suggest adding the following (and I'm happy to add this myself, along with CI test on wasm target)

#[cfg(target_arch = "wasm32")]
fn home_dir_inner() -> Option<PathBuf> {
    None
}

Notes

No response

Version

No response

[weihanglo]

You're absolute correct. home doesn't mean to be used on wasm target at this time. I wonder if the crate should also specify home as a target platform dependency.

Some related issues about what the return value should be:

• Add home_dir for WASI brson/home#26
• Home directory WebAssembly/wasi-filesystem#59

Could you also share the crate depending on home here so that we can have more data points to think about it?

BTW, a semi-related feature requests:

• Allow specifying a set of supported target platforms in Cargo.toml #6179

triage: @rustbot label -S-triage +S-needs-design +O-wasm

[lorepozo]

I encountered this in polars which moved from dirs to home in a recent release (dirs::home_dir returns None):

• polars can not be built for wasm from v0.29 pola-rs/polars#8783

[weihanglo]

I am pretty into this suggestion, similar to what you've proposed.

My suggestion would be to have home_dir return None, for now. That way, we don't need to block you here, and an implementation can be added later if we figure out what it should do.

std::env::home_dir also returns a None on unsupported platforms despite its deprecation.

I want to expand the proposal to align with things mentioned above — returns None on currently unsupported platforms. Simply starting from this:

/// Returns `None` on unsupported platforms.
///
/// We can figure out the implementation of each platform when needed.
#[cfg(not(any(unix, target_os = "redox", windows)))]
fn home_dir_inner() -> Option<PathBuf> {
    None
}

Let's do a quick poll.

@rfcbot fcp merge

[rfcbot]

Team member @weihanglo has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Eh2406
• @Muscraft
• @arlosi
• @ehuss
• @epage
• @joshtriplett
• @weihanglo

Concerns:

• support (home does not compile on wasm #12297 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[epage]

@rfcbot concern support

What is our overall plan/strategy for home?

Polars is a dataframe library and switch to home in pola-rs/polars#8449 because

• smaller
• cargo-team maintained

As a general home crate, cargo_home doesn't fit. Supporting wasm builds would also make sense.

As a crate meant for cargo and rustup, it has a very generalized name and seems people would be reading more into it being "cargo-team maintained" than we might want. In this case, supporting wasm builds miscommunicates the intended support.

So which is this intended to be and can we document it?

[ehuss]

My take is that home is primarily for rustup and cargo. I checked my box on this change because it is a relatively small change with what I think is little impact. But I think I would be against larger changes unless they are specifically to support cargo and rustup. So my perspective is to provide support on an as-available basis (like very small changes), but otherwise not accept larger changes.

We should have tagged @LucioFranco, since they said they would help with maintaining it. That's not a process we have handled too well.