When imported, the random module creates and seeds an implicit instance, even when it is never used.

The RNG is seeded from os.urandom, which as of python 3.5 uses the potentially blocking getrandom() call.

This causes problems e.g. on our build VMs that don't have true entropy, so getrandom() blocks forever -- unlike /dev/urandom, getrandom() in kernel waits until 128 bits of true entropy are available to reseed the RNG. And as it happens, the usual setup.py will very indirectly "import random" somewhere deep in its dependencies.

I can foresee a similar issue if someone uses python early in the boot process.

A possible workaround is to monkeypatch os.urandom (in this particular case, to return a string of zeroes and remove randomness entirely to get reproducible builds)