Test lower compat bounds?

[oschulz]

The current DocStringExtensions = "0.9.3" makes DifferentiationInterface incompatible with some packages that are still stuck on DocStringExtensions v0.8. Would it be possible to relax the version bound?

[gdalle]

Oh yes definitely. I wonder why CompatHelper didn't pick it up. Care to open a PR?

[oschulz]

I wonder why CompatHelper didn't pick it up

Because I wanted to extend it downwards to DocStringExtensions = "0.8, 0.9", not upwards. :-) But I can't find the package anymore that caused the trouble, maybe my dependencies are all v0.9-compatible now. I'll close this for now ...

[oschulz]

In any case, since DifferentiationInterface wil (hopefully) be wide used, maybe we could use https://github.com/julia-actions/julia-downgrade-compat to keep the dependency version bounds wide, but in a safe manner?

[adrhill]

Sounds like a great idea, thanks!

[gdalle]

While a good idea in principle, downgrade compat testing is more tricky than it looks because I perform Pkg operations inside the DI test suite. The DI test suite is split into one CI workflow per AD backend, and each of those workflows activates a custom environment like DI/test/Back/Diffractor/Project.toml. This is designed to avoid instantiating an environment with all backends at once, which is very tricky due to conflicts (especially on older versions of said backends).
The trouble with this method is that compat bounds of the DI package are not enforced in the environment activated on top of the test environment, which is why I had to explicitly bound Diffractor for instance. So I'm not sure how the GitHub action you refer to will handle that.

[adrhill]

each of those workflows activates a custom environment like DI/test/Back/Diffractor/Project.toml.

This could possibly be handled through the projects argument:
https://github.com/julia-actions/julia-downgrade-compat?tab=readme-ov-file#usage

# Comma-separated list of Julia projects to modify. The Project.toml files in all of
# these directories will be modified.
# Example: ., test, docs
# Default: .
projects: ''

[gdalle]

I don't think so because the individual Project.toml files don't store the compatibility bounds of AD backends for DI: that's stored in the main Project.toml file. So we would need a way to enforce these bounds in the stacked environment.

[gdalle]

Maybe we could add the packages of test/.../Project.toml to the current environment instead of activating a new one? Not sure if there is a command for that

[adrhill]

Could you point me to the location where the /test/Back environments get activated?

[gdalle]

https://github.com/gdalle/DifferentiationInterface.jl/blob/a0a96c7483a46cf09edbbb26a54c4262223430f1/DifferentiationInterface/test/runtests.jl#L21-L32