LoadError: UndefVarError: `use_prod5!` not defined

[cncastillo]

I have started to see the following error (example run: https://github.com/JuliaHealth/KomaMRI.jl/actions/runs/22325298426/job/64594078057?pr=725):

LoadError: UndefVarError: `use_prod5!` not defined

I believe that LinearOperators.jl (https://github.com/JuliaSmoothOptimizers/LinearOperators.jl) v2.13.0 introduced a change compared to v2.12.0 that causes this.

Do you have some clue of what could be happening? @aTrotier @nHackel

[tknopp]

Sounds like an API change within a minor version bump...

[nHackel]

I'll try to take a look today

[nHackel]

Two issues happened:

The first is that LinearOperatorCollection had some type-piracy with LinearOperators, in particular with a function which was now removed and caused the precompilation issue. I've added Aqua.jl and am currently removing the type piracy and other Aqua issues. As far as I can tell those are all just old code-branches which we don't actually use anymore.

The second issue is that LinearOperators changed some of the internal fields they use/expect in their methods on ::AbstractLinearOperators. We can now either try to target both <2.12 and 2.13 version by "faking" fields with getproperty or we can set a new lower bound and support 2.13 and onwards. In either way I have to make those changes in LinearOperatorCollection, MRIOperators and MPIReco. Those changes would be transparent to the user, the only difference would be the compat entry.

I am leaning towards a new lower bound and I've also asked for some clarification on what parts of an operator are considered to be public API and which are implementation details.

I'll need to find some more time to fix these issues, so in the meantime I can recommend users to pin their LinearOperators dependency to 2.12. I'm not sure what the registry says if we release one fixed versions of LinearOperatorCollection with an upper-bound and then lessen the upper-bound restriction once we have a proper solution in place

[amontoison]

Hello @nHackel,

Sorry for breaking your package. We have unit tests to check whether we break any packages, but only in JSO.

I propose restoring the old names of the internal fields and releasing version 2.14.0 if that can help you.

These internal fields, like Mv5, were not exported or documented, and since nobody uses them directly in our organization, I didn’t expect this to cause an error.

[nHackel]

Hello @amontoison, no worries! We kind of used internal fields of your package and had some type piracy as well 🏴‍☠️ (which I removed) so it was only a matter of time until this would happen😄

I've actually adapted most of our operators already to the new structures and from a naming perspective I do prefer the new names and overall all the changes Tim Holy did. So I think you can just leave things as they are and I finish fixing our operators based on the new structures.

it would be great if we could add documentation on how to implement custom operators and from then on have those be a "public interface". I could then also add a small custom operator test to LinearOperators.jl and then I think we are prepared against such breakage in the future