changed: bump ForwardDiff compat in ControlSystems + ControlSystemsBase also

[franckgaga]

more complete than #977

Some tests do not pass locally, but I think it was already the case before. (edit: just tested locally and yes, they were failing also before)

BTW, I can also try to do #975 myself.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.41%. Comparing base (5ab74cf) to head (9e00f30).
Report is 16 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #978   +/-   ##
=======================================
  Coverage   92.41%   92.41%           
=======================================
  Files          41       41           
  Lines        4981     4981           
=======================================
  Hits         4603     4603           
  Misses        378      378           

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[franckgaga]

Weird it does not pass locally but it passes here. Oh well, good news XP

[baggepinnen]

Did you verify that the tests actually ran with the new version? OrdinaryDiffEq might not yet be compatible so the tests might have run with an old version.

BTW, I'm in Jordan 🇯🇴 on holiday with very spotty internet connections, so my response times may be long 😊

[franckgaga]

Forgot to answer but yes you are right the test are executed with v0.10 instead of v1.0. I'm starting to understand why the CompatHelper forces the upper bound of compat entries.

But at the same time, I find hard to fully understand dependency issues. If everyone (as in every package) is waiting for everyone to update the ForwardDiff compat entries in their Project.toml because of this issue, it feels like nobody will update it. Except if we are "lucky" enough and everything is done in the correct order, for exemple:

1. A dependancy of OrdinaryDiffEq.jl update it's codebase to be compatible with ForwardDiff v1.0 and update the compat entry
2. OrdinaryDiffEq.jl update it's codebase to be compatible with ForwardDiff v1.0 and update the compat entry
3. ControlSystemsBase.jl update it's codebase to be compatible with ForwardDiff v1.0 and update the compat entry
4. ModelPredictiveControl.jl update it's codebase to be compatible with ForwardDiff v1.0 and update the compat entry (I decided to update it anyway, FYI)

And realistically, there is probably many steps before step 1. Am I misunderstanding something if I feel like "waiting for the other to update in the correct order" is almost a Mission: Impossible?

edit: I will post my question on discourse, I'm probably not the only one who does not understand this part.

edit2: Chris answered my quesiton here

edit3: Forgot to wish you a wonderful trip to Jordan, have fun as much as you can 🇯🇴 😄 !!!

[franckgaga]

I will close this PR since now you have two separate CompatHelper PRs. BTW, OrdinaryDiffEq.jl now supports ForwardDiff v1.0, so you may try to re-run the jobs in #977 and it may passes now.

[baggepinnen]

BTW, OrdinaryDiffEq.jl now supports ForwardDiff v1.0

Where did you get that from? It does not look like it here

https://github.com/SciML/OrdinaryDiffEq.jl/blob/master/Project.toml#L89

[franckgaga]

Hum weird, my mistake. I look at the same place yesterday and I saw "0.10, 1". I'm hallucinating like a LLM 😆

[baggepinnen]

You might have looked another package with a similar name, there are very many :P

[oscardssmith]

what's the way forward here? do you want me to run tests locally with deved OrdinaryDiffEq to force ForwardDiff@1? Alternatively, can this be merged as is?

[franckgaga]

I think it would be to wait that OrdinaryDiffEq.jl code and its ForwardDiff compat entry is updated. It is planned in the short term, as mentionned by Chris here.

[oscardssmith]

Yeah I'm the person in the process of doing so :) The tricky part is that a lot of libraries (e.g. MTK) rely on ControlSystemsBase so not releasing a new version of it makes it more effort to update the rest of the SciML stack.

[franckgaga]

Oh I see. It corroborate my theory above. It's even worse here since there is a circular dependency if I understand it right, so a correct order does not even exist here.

I think the only viable alternative is to dev everything, modify compat entries and test locally yes. What do you think @baggepinnen ?

[oscardssmith]

I think the only viable alternative is to dev everything, modify compat entries and test locally yes

yeah. That's been my life for the past couple weeks

[baggepinnen]

I don't mind merging if someone has tested locally

[oscardssmith]

running the tests locally, there was 1 failure (in ControlSystemsBase):

test_conversion: Test Failed at /home/oscardssmith/.julia/dev/ControlSystems.jl/lib/ControlSystemsBase/test/test_conversion.jl:221
  Expression: (hinfnorm(mp))[1] < 1.0e-10
   Evaluated: Inf < 1.0e-10

Any idea whether this is real?

[franckgaga]

I had the same results in my side when I tested it

[oscardssmith]

are tests clean on main?

[franckgaga]

Yes they were on my side, at least.

[baggepinnen]

The failing test should not depend on ForwardDiff, I'll look into it separately