Fix Aqua issue

[geoffroyleconte]

There are issues with Aqua because there are no deps declared for ChainRulesCore:

LinearOperators [5c8ed15e-5a4c-59e4-a42b-c7e8811fb125] does not declare a compat entry for the following weakdeps:
1-element Vector{Base.PkgId}:
 ChainRulesCore [d360d2e6-b24c-11e9-a2a3-2a2ae2dbcce4]

@tmigot

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (5ce0dc0) 96.58% compared to head (7db0139) 96.58%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #312   +/-   ##
=======================================
  Coverage   96.58%   96.58%           
=======================================
  Files          15       15           
  Lines        1055     1055           
=======================================
  Hits         1019     1019           
  Misses         36       36           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[github-actions]

Package name	latest	stable
CaNNOLeS.jl
DCISolver.jl
FletcherPenaltySolver.jl
JSOSolvers.jl
Krylov.jl
NLPModels.jl
NLPModelsModifiers.jl
PROPACK.jl
Percival.jl
QuadraticModels.jl
SolverTools.jl

[geoffroyleconte]

(LinearOperators) pkg> st
ERROR: Compat `ChainRulesCore` not listed in `deps` or `extras` section.

Should I move it to extras?

[tmigot]

@geoffroyleconte I wasn't sure, so I tried something. The hack to keep maintaining Julia 1.6 is to keep the extras section for weak deps.

[geoffroyleconte]

That's a bit weird to have a separate .toml in the tests no? We could keep my initial commit, I don't think there is an effect on performance?
Also, do you know why the documentation fails here?

[tmigot]

That's a bit weird to have a separate .toml in the tests no? We could keep my initial commit, I don't think there is an effect on performance? Also, do you know why the documentation fails here?

I know Julia have pushing for this for a while, see https://pkgdocs.julialang.org/v1/creating-packages/#Adding-tests-to-the-package for instance even though both approaches are still supported. I think it helps maintability to keep compatibility of versions used (even though it means we have to update these compatibility constraints sometimes).
This is not related to performance, but making sure it fits in the Julia eco-system.

No clue for the documentation, it seems everytime a PR has more than one commit it does this...

[geoffroyleconte]

OK. Just to make sure you have seen this line in the link you provided:

"
The exact interaction between Project.toml, test/Project.toml and their corresponding Manifest.tomls are not fully worked out and may be subject to change in future versions. The old method of adding test-specific dependencies, described in the next section, will therefore be supported throughout all Julia 1.X releases.
"

If that is not an issue you can merge (I cannot approve my own PR).

[tmigot]

Yes, it's true, and it seems this comment is here since version 1.2... but I still think it makes sense to have compat for tests. Even more now, that base packages have versions.
On the other side, I agree that it is slightly annoying to maintain 3 Project.toml per package (normal, test and doc)