Should the test environment precompile (w/ --check-bounds=yes) when precompiling a package environment?

[ericphanson]

Currently, if you precompile a package environment, the test dependencies are not precompiled. I think they should be, and test deps along with all regular deps should be precompiled with --check-bounds=yes, so that once a package env is precompiled, ] test can be run without additional precompilation of any dependencies.

@IanButterworth pointed out the technology for parallel precompiling with multiple settings of --check-bounds is already used for stdlibs when using Julia, so I think that could be used here.

Compiling deps w/ --check-bounds=yes as well doubles the number of packages to precompile, but without adding any additional depth to the precompile tree and therefore may not cost much in user time. Additionally precompiling the test-only deps could potentially add some depth, especially if there are heavy test deps. However, I think most of the time someone is precompiling a package env that has test deps, they will likely use them.

[giordano]

However, I think most of the time someone is precompiling a package env that has test deps, they will likely use them.

I'm not very convinced by this assumption. I don't think users who want to do quick numerical integration with QuadGK will be pleased to precompile Enzyme now.

[KristofferC]

Yeah, I am personally not convinced about doing this by default at all. Seems to me like something you should opt into in the precompile call for example

[ericphanson]

if you're doing integration with QuadGK, do you clone QuadGK, activate its environment, and then use it? I would think you would activate a temp env or script env and then add QuadGK there and use it there, with no test dependencies in your activated environment.

[IanButterworth]

IIUC there may be a future where we don't need --check-bounds=yes #50239 (comment)