search

nannou-org / nannou

A Creative Coding Framework for Rust.
https://nannou.cc/
5.99k stars 303 forks source link

Random distributions have moved to the rand_distr crate #798

Open Frojdholm opened 3 years ago

Frojdholm commented 3 years ago

As of rand 0.8 many useful distributions, such as the Gaussian/normal distribution, have been moved from rand::distributions to the rand_distr crate.

These are very useful for creative coding and I propose rand_distr should be re-exported together with the rand crate.

danwilhelm commented 3 years ago

I wonder if it should be canonical to use nannou's rand. Perhaps nannou should instead encourage users to import rand (and other third-party crates) separately. This would allow nannou to update internal crate versions without breaking end-user code.

Frojdholm commented 2 years ago

There are some advantages to having everything inside the nannou crate, it makes the initial setup faster and everything "just works". When I'm doing creative coding I want to iterate a lot. In this case my flow was broken by the missing distributions. I then had to go out and find them, update my dependencies and trigger a rebuild to get code completion working. Instead of just having them from the get go.

danwilhelm commented 2 years ago

Makes sense (and is I believe what was originally intended). I noticed a similar dilemma in this recent PR - apparently the crate daggy is included (perhaps for convenience) yet is not used by nannou itself https://github.com/nannou-org/nannou/pull/797#issuecomment-927501764

Frojdholm commented 2 years ago

At least for me personally, when doing creative coding convenience is more important than having the latest features. Also, correct me if I'm wrong, but even if these crates are re-exported by nannou it should still be possible to explicitly depend on and use a later version of the crate.

mitchmindtree commented 2 years ago

Thanks for the heads up!

I think the vague idea behind re-exports so far has been, if we're currently extending the crate or plan to in some way, we might as well re-export it too to make it easier to ensure users have access to a compatible version. For example, we extend rand with a handful of short-hand functions like random_range, random_ascii, etc.

That said, we don't currently extend noise at all, however we do re-export it for convenience. It's probably is useful for users in the sense that they can be sure that the noise and rand crates we re-export are always compatible. We should probably add a test so that CI can ensure this...

Convenience for the common cases is a strong motivation, though what's common for different folks can be a little less clear. I'm certainly in the heavy noise/rand-use camp :) That said, I also do much more audio and laser stuff than graphics stuff, but realise I'm probably in the minority here and don't mind the extra crate imports for those, especially as they have pretty deep dependency trees.

I'm also a little happier to re-export for convenience from the top-level nannou crate as long as we continue moving toward a more modular ecosystem. E.g. A user should be able to hand-pick the parts of nannou that they're after (e.g. nannou_core, nannou_wgpu) if they're concerned about extra bloat caused by unused re-exports. We're still lacking in a couple areas here, e.g. a nannou_draw with optional wgpu feature would be handy, maybe also a nannou_app which acts as the barebones for getting the event loop, windowing and input working. It's probably also worth considering whether or not nannou should expose features for all these to make it easier to disable one or two things. I've opened an issue for this.

Maybe it's also worth considering a nannou_rand crate that includes our helpers along with a feature for enabling the re-export of rand_distr? We could then re-export nannou_rand as rand in nannou and enable the distr feature by default.