docs should highlight that extensions need to be triggered in order to be analyzed

[giordano]

Over at NumericalEarth/Breeze.jl#195 I mentioned that there's an import error

  ExplicitImportsFromNonOwnerException
  Module `BreezeCloudMicrophysicsExt` has explicit imports of names from modules other than their owner as determined via `Base.which`:
  - `prettysummary` has owner `Oceananigans.Grids` but it was imported from `Oceananigans.Utils` at `/Users/runner/work/Breeze.jl/Breeze.jl/ext/BreezeCloudMicrophysicsExt.jl:210:28`

which is somehow reported inconsistently. For example, of all the jobs in https://github.com/NumericalEarth/Breeze.jl/actions/runs/19600740942/job/56131898424#step:6:756, only Julia v1.12 on macOS reports it, but not even always, CI jobs in PRs don't seem to ever report it. To reproduce it, use

]add https://github.com/NumericalEarth/Breeze.jl#27a3949a77e0681524606c01368a406dda5e2f38 Oceananigans@v0.101.3

(the import error will be fixed, either in Breeze or Oceananigans, so you need to fix the versions of the involved packages)

[giordano]

Do I understand correctly that ExplictImports will analyse the code of extensions only when the relevant trigger modules are loaded? In NumericalEarth/Breeze.jl#201 I'm now always loading the relevant module and the test failures happens everywhere, as expected. I guess before it was happening only on some systems because we use ParallelTestRunner, and the trigger module would be loaded depending on the exact scheduling of the tests on each worker. In this case there's probably not too much to do here, maybe warn users that they need to explicitly load all the triggers to analyse the extensions?

[ericphanson]

We do say

ExplicitImports.jl/src/ExplicitImports.jl

Line 110 in 4fedbab

If `mod` is a package, we can detect the explicit_imports in the package extensions if those extensions are explicitly loaded before calling this function.

Maybe it should be more prominent somewhere?