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.

[ehuss]

Adding more context: When we originally moved home to the cargo repo, it was because it is primarily used by cargo and rustup, and it needed a place to live. @LucioFranco indicated they would also help with maintenance, though our expectations were that it should need very little maintenance for cargo/rustup's use cases. I think it might be the wrong takeaway for people to think it is now "cargo team blessed", and that it is a good fit for general-purpose use. We should decide on what exactly that means, but I would like to give @LucioFranco some time to respond if they are still available as a maintainer. Otherwise, we may need to better communicate the status and purpose of the crate.

[epage]

For me, I'm not against general improvements but more so if we clarify the intended "blessed"-ness of this package to Polars, would they move away from it and the request for wasm support would go away?

[epage]

Not a blocker but something else for us to keep in mind is that to support wasm means we need to at least verify we build in wasm which means we would need another CI job running. This likely wouldn't "break the bank" on our CI times but we should be mindful of it.

[weihanglo]

support wasm means we need to at least verify we build in wasm which means we would need another CI job running

This is a good point! Now I am more convinced that we shouldn't support any further use case unless the original maintainer or someone stands out and commits to it.

…but I would like to give @LucioFranco some time to respond if they are still available as a maintainer.
…So which is this intended to be and can we document it?

My 2 cents before Lucio puts their words here:

`home` is merely for rustup and cargo's use cases. You are suggested to use a
more general package on crates.io for other scenarios. `home` always returns
`None` for unsupported platforms, which might be unexpected.

[LucioFranco]

Sorry I was taking a break for a while and this issue then escaped me. I think adding support for wasm doesn't make much sense anyways since its not a nix or windows platform. In addition, I don't think any of us have the bandwidth to figure that out at the moment.

[weihanglo]

Hey Lucio. Glad you're coming back! And thanks for having a look at this.

By not supporting wasm and other platforms, do you prefer always returning a None, or compile failure? I am okay with either way.

[ehuss]

@LucioFranco Just checking in again if you think you'll have time to help with this issue or the maintenance of home in general. Weihang indicated you have been busy with things lately, so I understand. Just to relay that the cargo team doesn't want to take on the maintenance of home as a general-purpose crate for the community, so we would like to avoid getting pulled into spending time on issues like these. If you don't think you will have time for the foreseeable future, we are thinking of documenting that home is not intended for anything but use inside of cargo and rustup, and suggest people use some other crate instead.

Also note that in rust-lang/rust#71684 there seems to be some interest in providing a new solution in std, which might be an option for some if someone wants to try to help there.

[LucioFranco]

@ehuss Hi! I currently don't have time for home so I think the idea of keeping home a crate of internal use is a good idea. Thanks for the reach out!

[djc]

Is this something I could help out with? At this point the home crate has 370 dependents on crates.io and 60k downloads per day on weekdays, so it feels like it is a de facto standard whether the Cargo team likes it or not, and not doing the (presumably limited amount of) maintenance necessary to make this a broadly acceptable solution feels like a waste.

[epage]

@djc we talked about this in the cargo team meeting and we are interested in the help. Additionally, we feel more of that time should probably be spent towards an ACP to merge this into the standard library as there is interest in such a thing

Independent of helping with home, is that something you'd be willing to take on?

[djc]

Yup, I'll see if I can squeeze out an ACP.

[epage]

@djc please tag me on it when you do and feel free to pull me in if you want help with any part of it!

[ehuss]

I'm going to cancel the FCP here since I don't think it is likely to move forward.

@rfcbot cancel

The team would like to see someone open an ACP as mentioned above in #12297 (comment). @joshtriplett (who is also on the libs team) has also indicated they would like to see that route move forward.

[rfcbot]

@ehuss proposal cancelled.

[epage]

FYI rust-lang/libs-team#372