one new feature, released in v1.14.0: check_all_explicit_imports_are_public and check_all_qualified_accesses_are_public now accept a from keyword argument to limit checks to names from particular modules (#134)
8 bugfixes:
v0.14.2
Fix issue where explicitly imported macros aren’t detected as imported. This may cause previously undetected stale explicit imports of macros to now be detected. (#159)
Fix bug in kwarg default values, e.g. where f(; convert=convert) would not detect the usage of convert as external. (#148)
Fix scoping issues in default values of positional arguments (#147), similar to above for kwargs
Fix bug where if a field name in a struct was the same as the usage of a global in a constructor, that usage would be missed. (#146)
Fix bug where names exported by Base and re-exported by other modules are incorrectly suggested to be explicitly imported from those other modules. (#145)
As a result, ExplicitImports.jl should be more accurate in identifying implicit imports and stale explicit imports, and generally work a bit more the way it should.
We also have added some “integration tests” (or reverse-dependency tests) where we run checks on particular packages to surface unexpected breakage. See here. We can add more packages as well- file an issue or PR if you are interested in your package being tested this way.
PSA: Some of these bugfixes (especially the one about macros) may result in test failures if you use ExplicitImports.jl during your package’s tests and relied on the previously-inaccurate results.
Is there a technical limitation for being able to do something similar for check_no_implicit_imports? I have an interested in that possibility Edit: uhm, maybe I initially misunderstood the application, and this makes sense only for those checks about methods coming from another module
would check only that explicit imports from the DataFrames module (or its submodules) are all public.
There’s lots of other configuration the checks have, ignore, skip, etc. If you have a use that isn’t covered, feel free to open an issue. I’m hoping to make them flexible enough they can be used in partially-migrated codebases and things like that.
I think what I wanted to use is ignore, but ignore=(MyModule,) doesn’t seem to ignore submodules of MyModule (I feel like I tried this before already and may explain why I didn’t use it). I guess I’ll have to list all submodules.
If you’re talking about check_no_implicit_imports, then it should handle submodules:
Additionally, the keyword `ignore` can be passed to represent a tuple of items to ignore. These can be:
* modules. Any submodule of `mod` matching an element of `ignore` is skipped. This can be used to allow the usage of implicit imports in some submodule of your package.
* symbols: any implicit import of a name matching an element of `ignore` is ignored (does not throw)
* `symbol => module` pairs. Any implicit import of a name matching that symbol from a module matching the module is ignored.
Mosè indeed found the ignore kwarg was not ignoring submodules as intended; that has been fixed in v1.15.0 of ExplicitImports. Here are the release notes.
New features
support ignore kwarg for all check_* functions (#165)
add new test_* API functions for better integrations into Test.jl testsuites (and to help with Aqua integration) (#143)
new functions: test_explicit_imports, test_no_implicit_imports, test_no_stale_explicit_imports, test_all_explicit_imports_via_owners, test_all_explicit_imports_are_public, test_all_qualified_accesses_via_owners, test_all_qualified_accesses_are_public, test_no_self_qualified_accesses