Could GLOBAL_RNG be set like an environment variable?

[mkborregaard]

I'd like to change the default RNG on my system to one of the more efficient implementations from RandomNumbers.jl, so that rand() without explicitly passing an RNG works out of the box with the alternative RNG. This would be particularly useful for running library code (which would normally just use rand() without specifying the RNG) on a faster RNG.
I understand from https://github.com/sunoru/RandomNumbers.jl/issues/30 that setting GLOBAL_RNG directly is currently not possible unless a Base.Random function is defined that sets it.
See also #18488 which discusses the use of GLOBAL_RNG.

[StefanKarpinski]

This would essentially prevent precompiling anything that depends on GLOBAL_RNG.

[StefanKarpinski]

But I agree that we really should have some solution to this and that ideally, the global RNG type should be set explicitly any time a seed is provided.

[mkborregaard]

Sounds great. I can see the technical issue, but it would be a nice feature to have on the user side.

[StefanKarpinski]

The environment variable approach is interesting since it's able to affect things before any Julia code actually runs. That could potentially be helpful, but this is still a tricky issue.

[stevengj]

You can set it with eval(Base.Random, :(GLOBAL_RNG = $newrng)), though this will give a warning about redefining a global constant.

If we make GLOBAL_RNG a per-thread array ala #10441 then it will be mutable.

[newptcai]

There is also the problem of unittest. The document says

Before the execution of the body of a @testset, there is an implicit call to Random.seed!(seed) where seed is the current seed of the global RNG.

So if we cannot change global GLOBAL_RNG, we cannot easily switch to another random number generator without change @testset

[mbauman]

Is this now possible? Seems like there'd be multiple hooks that could accomplish this now.

[oscardssmith]

Possibly more important is that with 1.7, I don't believe you need to do this at all. Since we moved to a faster task local rng, I don't think that doing this would provide the benefit it used to

[StefanKarpinski]

The direction we've gone here is that if you care about a specific PRNG sequence then you should not use the global default RNG at all, but should instead use an explicitly constructed and passed around RNG object. In particular, if you want the sequence to never change then you should use StableRNGs.jl, which promise never to change and prioritize stability over performance.