Resolve design of rand integration: Depend directly on rand now?

[bluss]

See issue #166 for the whole discussion.

[bluss]

@daniel-vainsencher By the way, ndarray-rand is finally published as a crate.

Ok, this has been released as ndarray-rand 0.1. The public vs non-public dependency choice is interesting, and we maybe want to go the other route (non public dependency) in the future. It allows using rand without it being a liability too.

[bluss]

We can now consider depending directly on rand from ndarray (and dropping ndarray-rand).

Renaming dependencies should make it possible to depend on both Rand0.8 and other versions, right? (Newer versions if they come out). So maybe if the design is a trait like RandomExt_0_8, is that too ugly?

[vks]

The non-uniform distributions are now in rand_distr, and they use the num_traits::float::Float trait.

[vks]

Renaming dependencies should make it possible to depend on both Rand0.8 and other versions, right?

Yes, but why do you want to directly depend on two different versions?

[bluss]

rand is a public dependency (we use its traits publicly) - we want to avoid the coupling, that's the reason for the ndarray-rand indirection. For example we don't want an update to support a semver-breaking upgrade of rand, to be semver-breaking for ndarray. Adding rand versions after the fact accomplishes that (and ndarray-rand accomplishes that for ndarray today).

Another example is blas-src which is decoupled the same way, but it's using a much more oldschool interface to mediate (cblas-sys).