Depdendency explosion

[piscisaureus]

I noticed that depending on rand now comes with two different versions of rand_core.
And in fact it seems that it is rand_core itself, depending on it's future self.

I presume this is a bug... if not I'd kindly suggest to try a slightly more minimalistic approach.
FYI all those crates still compiled just fine when I manually replaced rand_core v0.3 by v0.4 everywhere.

D:\test\testrand>cargo tree
testrand v0.1.0 (D:\test\testrand)
└── rand v0.6.4
    ├── rand_chacha v0.1.1
    │   └── rand_core v0.3.1
    │       └── rand_core v0.4.0
    │   [build-dependencies]
    │   └── autocfg v0.1.2
    ├── rand_core v0.3.1 (*)
    ├── rand_hc v0.1.0
    │   └── rand_core v0.3.1 (*)
    ├── rand_isaac v0.1.1
    │   └── rand_core v0.3.1 (*)
    ├── rand_os v0.1.1
    │   ├── rand_core v0.3.1 (*)
    │   └── winapi v0.3.6
    ├── rand_pcg v0.1.1
    │   └── rand_core v0.3.1 (*)
    │   [build-dependencies]
    │   └── rustc_version v0.2.3
    │       └── semver v0.9.0
    │           └── semver-parser v0.7.0
    ├── rand_xorshift v0.1.1
    │   └── rand_core v0.3.1 (*)
    └── winapi v0.3.6 (*)
    [build-dependencies]
    └── autocfg v0.1.2 (*)

D:\test\testrand>cargo build
    Updating crates.io index
  Downloaded rand v0.6.4
  Downloaded rand_xorshift v0.1.1
  Downloaded rand_chacha v0.1.1
  Downloaded rand_hc v0.1.0
  Downloaded rand_isaac v0.1.1
  Downloaded winapi v0.3.6
  Downloaded rand_core v0.3.1
  Downloaded autocfg v0.1.2
  Downloaded rand_pcg v0.1.1
  Downloaded rand_os v0.1.1
  Downloaded rand_core v0.4.0
  Downloaded rustc_version v0.2.3
  Downloaded semver v0.9.0
  Downloaded semver-parser v0.7.0
   Compiling semver-parser v0.7.0
   Compiling winapi v0.3.6
   Compiling autocfg v0.1.2
   Compiling rand_core v0.4.0
   Compiling rand_core v0.3.1
   Compiling rand_chacha v0.1.1
   Compiling rand v0.6.4
   Compiling semver v0.9.0
   Compiling rand_xorshift v0.1.1
   Compiling rand_isaac v0.1.1
   Compiling rand_hc v0.1.0
   Compiling rustc_version v0.2.3
   Compiling rand_pcg v0.1.1
   Compiling rand_os v0.1.1
   Compiling testrand v0.1.0 (D:\test\testrand)
    Finished dev [unoptimized + debuginfo] target(s) in 25.49s

[dhardy]

Ha, sorry, not a bug. We have to use an upgrade shim to make rand_core always use the latest version, otherwise there are multiple versions of its traits and users run into lots of weird problems. The next versions of other crates released will all depend on rand_core 0.4, but 0.3.1 is merely a re-export shim so no harm in having it.

As for the rest — we haven't included the kitchen sink, but there is a lot of functionality we have chosen to cover, and we made the decision to go modular, which means lots of small libs. Some of that will be reduced in the future once we remove deprecations.

What functionality do you use?

[piscisaureus]

What functionality do you use?

I'm not, but very many packages that I use have rand as a dependency, so I've watched rand_isaacs/pcg/foobar build many times.
Most of those dependencies only use rand in their tests/benchmarks, and then 80% uses only thread_rng().
(The exceptions are ring/rustls, they need a cryptographic RNG -- fair enough, add one to the crate budget.)

I'd prefer if ring was just a single, small crate with the most essential features.

[dhardy]

Look, I think you do have a good point here that we pull in a lot of crates, but I also need a better answer than that to do much about it. You give an example which is merely a test crate — well, there's no need to import Rand if you're not using its functionality. You then mention crates only using thread_rng, but presumably these do actually use some of the functionality implemented on the RngCore / Rng traits, so the question is what?

Your test build pulls in 13 crates besides rand:

• rand_core is required (to allow rand to use RNGs implemented in other crates)
• the second rand_core is only a transitional shim with zero code (just re-exports)
• rand_os is required for seeding, as is rand_jitter (now also an external crate)
• rand_hc is used by StdRng and ThreadRng (the alg may change in the future, but some CSPRNG is required)
• rand_pcg is used by SmallRng
• autocfg is used for Rustc version detection; this crate may well become the standard tool to use for this so used by plenty of other crates (there's discussion on this here)
• rustc_version was used instead of autocfg but has been replaced; unfortunately a rand_pcg update is blocked by pcg: make bincode as dev-dependency #663 so this is still here for now
• semver and semver-parser are only required by rustc_version
• winapi (or libc on Linux or several other platform-specific crates) is required by rand_os
• rand_chacha, rand_isaac and rand_xorshift are all deprecated dependencies and will be removed soon

So what does that gives us? In the near future we should have +1 -7 dependencies, bringing us down to 7. Of the remainder:

• rand_core, autocfg, one of (winapi, libc, etc.), and one CSPRNG alg (currently rand_hc) are required
• rand_os, rand_jitter are in flux (see OsRng run-time failure / the rand_os crate / modularity #681) but should be 1-3 crates eventually (probably 2)
• rand_pcg is one extra dependency to enable SmallRng, which is reasonably widely used, though could potentially be deprecated

So there is already a plan to reduce the dependencies by approx half. Is this good enough?

---

The other angle is moving ThreadRng to its own crate to allow a smaller dependency for crates which don't need the other functionality. However, I suspect it is not worth doing:

• this crate would only have 1-2 less dependencies (rand_pcg and possibly autocfg)
• this is yet another crate for users of Rand as a whole
• likely someone would want some extra functionality, such as generating uniform integers within a given range, and thus have to add a dependency on rand anyway (or roll their own code which is easy to get wrong with bias and off-by-one errors and would miss our various specialisations and optimisations)