[ANN] ExplicitImports.jl: tooling to help use and maintain explicit imports in your package

ExplictImports v1.14.2

Since last time, we’ve had:

  • 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)
    • v1.14.1
      • Fix type parameter issue (#141)
    • v1.13.2
      • Fix ExplicitImports to work with --depwarn=error (#132)
    • v1.13.1
      • improve function argument parsing (#130)

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.

3 Likes

Is there a technical limitation for being able to do something similar for check_no_implicit_imports? I have an interested in that possibility :sweat_smile: Edit: uhm, maybe I initially misunderstood the application, and this makes sense only for those checks about methods coming from another module

Yeah, the way these work is (from the docs):

Alternatively, the from keyword can be used to apply the public names check to only certain modules (and their submodules).

For example,


@test check_all_explicit_imports_are_public(MyPackage; from=(DataFrames,)) === nothing

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.

Could be there’s a bug though

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
  • add --test flag to CLI app (#166)

Bug fixes

  • fix ignore to properly ignore submodules of ignored modules (#165)
5 Likes