Uuid::new_v4() compiles and then panics for wasm32-unknown-unknown target

[zrzka]

Is your feature request related to a problem? Please describe.

I do use uuid crate in my crate, which can be used as a pure Rust library or as an isomorphic NPM package (node & browser). The only feature I do use is random UUID (v4) generation.

It panics:

panicked at 'could not initialize thread_rng: No entropy sources available (permanently unavailable)', /Users/robertvojta/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.5.5/src/rngs/thread.rs:84:17

Example of what we do is in this issue. Our uuidv4() function source code.

Describe the solution you'd like

Generate UUID v4 even when compiled for the wasm32-unknown-unknown target.

Is it blocking?

Kind of. Not a high priority.

Describe alternatives you've considered

Thinking about using Math.random in my function if the target is wasm32-....

Other

Not sure if this is the uuid crate problem or it lies somehwere deeper inside this whole bleeding edge stuff.

[Dylan-DPC-zz]

Hi. Thanks for reporting this.

Rand added wasm support to 0.6, while we are still using 0.5. (We have a PR to upgrade it to 0.6 but haven't merged it yet).

You can test it by depending on the dependabot/cargo/rand-0.6 branch instead of master.

[zrzka]

@Dylan-DPC thanks, just tried ...

Browser

panicked at 'could not initialize thread_rng: No entropy sources available
  (permanently unavailable)', .../rand-0.6.1/src/rngs/thread.rs:82:17

Node

panicked at 'could not initialize thread_rng: No entropy sources available
  (permanently unavailable)', .../rand-0.6.1/src/rngs/thread.rs:82:17

Testing with:

uuid = { 
  features = ["v4"],
  git = "https://github.com/uuid-rs/uuid",
  branch = "dependabot/cargo/rand-0.6" 
}

[zrzka]

Not sure if this comment is related to my issue somehow:

use with --target wasm32-unknown-unknown --features=stdweb

Will check tomorrow if it's gated behind this feature.

[zrzka]

@Dylan-DPC it's not enough to update to 0.6. One has to use stdweb or wasm-bindgen feature with wasm32-unknown-unknown target. Even the error message says it:

No entropy sources available (permanently unavailable)

Just checked the rand source code. It works (node & browser) if I change uuid crate dependency to:

 [dependencies.rand]
 optional = true
-version = "0.5"
+version = "0.6"
+features = ["wasm-bindgen"]

One can use stdweb or wasm-bindgen.

[KodrAus]

Hmm, this doesn't seem ideal to me... We'd either have to pick one of the wasm-bindgen or stdweb features in the rand dependency unconditionally. I haven't been keeping up with the wasm space so am not sure which of these features would be the better one.

We don't currently claim any wasm support in uuid (although it might be nice to figure out) so a workaround until we have some idea of what that should look could be to depend on rand yourself with one of the features you want.

@zrzka Do you have any thoughts?

[zrzka]

@KodrAus there's one way. uuid crate can have same features (stdweb, wasm-bindgen) as rand and these features can be passed to uuid crate dependencies.

uuid crate Cargo.toml:

[dependencies.rand]
optional = true
version = "0.6"

[features]
wasm-bindgen = ["rand/wasm-bindgen"]
stdweb = ["rand/stdweb"]

My crate Cargo.toml:

[dependencies]
uuid = { features = ["v4"], path = "../uuid" }

[target.wasm32-unknown-unknown.dependencies]
uuid = { features = ["wasm-bindgen"], path = "../uuid" }

This works for me. And anyone can still use uuid as it is or with either stdweb or wasm-bindgen feature, which just enables this feature in the rand crate.

I also tried to add ...

[target.wasm32-unknown-unknown.features]
wasm-bindgen = ["rand/wasm-bindgen"]
stdweb = ["rand/stdweb"]

... to enable these features for wasm32 only, but it seems that it doesn't work with ...features, just ...dependencies.

Maybe @alexcrichton can sched a light on this, I mean, what's the recommended approach. IIRC I saw Alex in all these wasm32 commits in the rand crate.

Another option, just for me, is to disable v4 feature on the UUID, copy & paste new_v4() to my crate, add rand dependency and generate / crate UUID v4 by myself.

[Dylan-DPC-zz]

It is a good idea to add wasm support for UUID. @zrzka since you have already started digging into this, are you open to sending a PR that adds the feature? we will mentor you. If you don't have time, I'll look into adding it later. Thanks

[zrzka]

@Dylan-DPC yup, going to do it now.

[zrzka]

Did the PR, but not sure if it's the right thing to do. It works for me and I have a temporary fix for my issue. No need to hurry.

What bothers me is this wasm-bindgen feature. There's a crate with the same name and you can't have a feature and a dependency with the same name. If, and if, you'll want to create wasm-bindgen based NPM package from the uuid crate, it will fail because of the wasm-bindgen feature = name conflict. Not sure if it applies to rand crate as well, because wasm-bindgen feature is not in the Cargo.toml, it's in the code only. Just thinking aloud, hypothetical example ...

[alexcrichton]

For now we don't have a great way to solve this, but the recommended approach would be to have an feature name like wasm-bindgen and such which is enabled by consumers (and transitively enables the feature in required dependencies). Which is to say I think you're already on the right track!

[KodrAus]

@alexcrichton Hm, this isn't going to play particularly nicely with dependencies that are optional to begin with though, right? So with a wasm-bindgen feature we can't not depend on rand, because we have to enable it along with its wasm-bindgen feature.

But if this is the way we're recommending folks do this then we should follow it here, so at least uuid is in the same boat as everyone else if we try come up with a more scalable solution later.