Carsten Bauer

Your questions are generally better placed at [discourse.julialang.org](http://discourse.julialang.org).

> [...] then we could easily run this at MPI.jl build time. Question from the sideline: Wasn't the idea to not have a build step anymore? (Oh I see, Valentin...

MKL_jll seems to be lazy, see discussion over at https://github.com/JuliaLang/Pkg.jl/issues/2664. However, don't know what that laziness means exactly. Does it also allow optional download without an Override.toml?

> I am sympathetic with not wanting to download unnecessary binaries, but making them lazy has its own problems, I shuder thinking of a thousand processes hitting the network and...

BTW, if no one disagrees with the described approach, I'm willing to test-implement this in a PR (and a corresponding PR to Yggdrasil). Actually, I might try the same strategy...

Works nicely for MKL.jl, see my PR [here](https://github.com/JuliaLinearAlgebra/MKL.jl/pull/84). Though, MKL.jl is simpler and I could avoid `build.jl` altogether.

Yes, I will give it a shot next week.

> I think the solution should be resolving [JuliaLang/Pkg.jl#2664](https://github.com/JuliaLang/Pkg.jl/issues/2664), coming up with custom solutions for each package is not useful, nor scalable. BTW, my experience with Pkg is that if...

> It is meant as a successor/replacements to `Overrides.toml` Ah, that makes sense (and explains my confusion) 😄

I see the issue but don't think it's such a big caveat. The fact that environment variables might only effect the `] build MyPackage` (or precompilation) phase of a package...