feat!: test imports and use of private APIs through ExplicitImports.jl #369
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,7 +1,13 @@ | ||
| [deps] | ||
| Aqua = "4c88cf16-eb10-579e-8560-4a9242c79595" | ||
| Changelog = "5217a498-cd5d-4ec6-b8c2-9b85a09b6e3e" | ||
| Documenter = "e30172f5-a6a5-5a46-863b-614d45cd2de4" | ||
| DocumenterInterLinks = "d12716ef-a0f6-4df4-a9f1-a5a34e75c656" | ||
|
|
||
| [compat] | ||
| Changelog = "1" | ||
| Documenter = "1" | ||
| DocumenterInterLinks = "1.1.0" | ||
|
|
||
| [sources] | ||
| Aqua = { path = ".." } |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,7 @@ | ||
| # Explicit imports | ||
|
|
||
| ## [Test function](@id test_explicit_imports) | ||
|
|
||
| ```@docs | ||
| Aqua.test_explicit_imports | ||
| ``` |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,13 @@ | ||
| """ | ||
| test_explicit_imports(m::Module; kwargs...) | ||
|
|
||
| Run the various tests provided by the package [ExplicitImports.jl](https://github.com/ericphanson/ExplicitImports.jl). | ||
|
Member
There was a problem hiding this comment. I don't understand: if
Contributor
Author
There was a problem hiding this comment. To have everything in one place instead of requiring users to combine several packages when testing code quality
Member
There was a problem hiding this comment. But we are missing JET report_package, SnoopeCompile invalidation tests, Runic (or JuliaFormatter???) code formatting. Sarcasm aside, I don't agree with this being a useful goal.
Contributor
Author
There was a problem hiding this comment. You think this is sarcasm but I actually think these would be other legitimate additions to Aqua
Contributor
Author
There was a problem hiding this comment. The main question is what the community wants, because you and I are obviously on opposite sides ^^
Member
There was a problem hiding this comment.
Is it, though? It sure is useful what "the community" wants, but it is also exceedingly difficult to actually find that out. In particular don't find 15 likes on an issue convincing: first off, those are not really high numbers (relative to the size of the Julia community). Moreover you don't see dislikes / don't care / "am afraid of this". And finally I am not convinced that this actually means something (it is not uncommon for people to "like" something in the abstract but then not "like" it in practice once it is there) But most importantly to me, the set of people who even see these discussions, and comments/likes, is highly self-selected: People who see it are likely to already be interested in enforcing standards, of dealing with the resulting work, they might even read the release notes for Aqua and opt-in to new checks. (Plus: one can only "like" in Discourse, there is no way to "dislikes"; and 7 or 15 are also not very impressive numbers to start with) But in my work and daily interactions with people who need to work with Julia code and packages but just want to get stuff done, I see a very different picture. There Julia and package updates are seen as something to dread, as something that causes constant churn by introducing breaking changes. I am glad when I can convince these people to use Aqua at all. Each new test is a new hurdle that needs to be carefully weighed: how important is this test, how easy is it to understand what is even about (and why it matters) how hard is it to make it pass (other than turning it off)? In my subjective view, adding And JET, SnoopCompile etc. are all nice tools in theory, but like the "problems" this PR "revealed" in Aqua itself, they often are very tricky to resolve and require convincing other package authors and even Julia itself to make changes. Some people love spending their time with that. Others need to get their job done first. Again, this is a tricky balance, and admittedly where the cutoff is is subjective. For me one rule of thumb is that stuff were a fix often requires changes outside of your own package is too far. There is also the classic dependency problem: by tying Aqua to ExplicitImports we also become beholden to decisions you make: if If you really want a "one stop solution"), I suggest to make a new
Member
There was a problem hiding this comment. I think Aqua has a pretty general scope:
There's nothing that actually unifies the particular set of checks it does under one theme, they are just a bunch of useful checks. So to me it seems weird to say whatever checks already exist are OK, but other checks are not. And Here's a random idea:
So anyone can easily stick with Could also have There was a problem hiding this comment. Instead of "versions" we could call these "levels of strictness". Like e.g. |
||
|
|
||
| # Keyword Arguments | ||
|
|
||
| Same as those of the function [`ExplicitImports.test_explicit_imports`](@extref). | ||
| """ | ||
| function test_explicit_imports(m::Module; kwargs...) | ||
| # TODO: explicitly list kwargs here? | ||
| ExplicitImports.test_explicit_imports(m; kwargs...) | ||
| end | ||
Uh oh!
There was an error while loading. Please reload this page.