Version 1.5.7 brakes ModelingToolkit

[ufechner7]

Since this morning I could not install ModelingToolkit any longer. I got the error:

The following 1 direct dependency failed to precompile:

ModelingToolkit [961ee093-0014-501f-94e3-6117800e7a78]

Failed to precompile ModelingToolkit [961ee093-0014-501f-94e3-6117800e7a78] to "/tmp/testdepot/compiled/v1.10/ModelingToolkit/jl_TkA4eb".
ERROR: LoadError: MethodError: setproperties_object(::SymbolicUtils.BasicSymbolic{Real}, ::@NamedTuple{metadata::Base.ImmutableDict{DataType, Any}}) is ambiguous.

Candidates:
  setproperties_object(obj::SymbolicUtils.BasicSymbolic{T}, patch) where T
    @ SymbolicUtils /tmp/testdepot/packages/SymbolicUtils/EGhOJ/src/types.jl:92
  setproperties_object(obj, patch::NamedTuple)
    @ ConstructionBase /tmp/testdepot/packages/ConstructionBase/c2lWA/src/ConstructionBase.jl:205

Possible fix, define
  setproperties_object(::SymbolicUtils.BasicSymbolic{T}, ::NamedTuple) where T

Stacktrace:
 [1] setproperties(obj::SymbolicUtils.BasicSymbolic{Real}, patch::@NamedTuple{metadata::Base.ImmutableDict{DataType, Any}})
   @ ConstructionBase /tmp/testdepot/packages/ConstructionBase/c2lWA/src/ConstructionBase.jl:136
 [2] set
   @ /tmp/testdepot/packages/Setfield/PdKfV/src/sugar.jl:197 [inlined]
 [4] setmetadata(s::SymbolicUtils.BasicSymbolic{Real}, ctx::DataType, val::Tuple{Symbol, Symbol})
   @ SymbolicUtils /tmp/testdepot/packages/SymbolicUtils/EGhOJ/src/types.jl:657
 [5] top-level scope
   @ /tmp/testdepot/packages/ModelingToolkit/GJiqn/src/ModelingToolkit.jl:189
 [6] include
   @ ./Base.jl:495 [inlined]
 [7] include_package_for_output(pkg::Base.PkgId, input::String, depot_path::Vector{String}, dl_load_path::Vector{String}, load_path::Vector{String}, concrete_deps::Vector{Pair{Base.PkgId, UInt128}}, source::Nothing)
   @ Base ./loading.jl:2222
 [8] top-level scope
   @ stdin:3
in expression starting at /tmp/testdepot/packages/ModelingToolkit/GJiqn/src/ModelingToolkit.jl:1

Downgrading ConstructionsBase to version 1.5.6 fixed the issue.

[jw3126]

Thanks! I consider setproperties_object an implementation detail and did not expect it to be overloaded by external packages:

setproperties_object(obj::SymbolicUtils.BasicSymbolic{T}, patch) where T
    @ SymbolicUtils /tmp/testdepot/packages/SymbolicUtils/EGhOJ/src/types.jl:92

If they need to overload, the overload should probalby have signature setproperties_object(obj::SymbolicUtils.BasicSymbolic{T}, patch::NamedTuple)

[ufechner7]

See also: https://discourse.julialang.org/t/modelingtoolkit-fails-to-pre-compile/118361/2 for a discussion in which package this should be fixed.

[devmotion]

There's an open PR (which IMO should also be backported): JuliaSymbolics/SymbolicUtils.jl#634

[ChrisRackauckas]

For backwards compatability can this get a deprecation? We can patch SymbolicUtils a bit but this is pretty disruptive. It's fine for it to only be considered in hindsight but There's many versions of this in earlier Symbolics going back years, and patching all version is much more difficult in comparison to just putting one depwarn.

[jw3126]

Sure feel free anybody to make a PR. I am a little unclear though when exactly you want a warning.

[MilesCranmer]

This broke a bunch of my CI, could this change be reverted?

[aplavin]

Hmm, I thought SymbolicsUtils fixed their bug (judging by comments above)... That package defined a method for an internal ConstructionBase function instead of the corresponding public function.
Are your CI failures also caused by that SymbolicUtils bug, or something different?

[MilesCranmer]

In my env, SymbolicUtils is limited to a version range (by some other package I guess) that wasn’t patched. Unless you were to patch every version of SymbolicUtils, there are some versions with this issue.

I think the right way to solve this is to patch it here. It’s too much of a disruptive change to have it be a minor version release let alone a patch release

[ChrisRackauckas]

We patched all the way down to v0.19 IIRC.

[rafaqz]

I get your sentiments, but adding methods to undocumented internals is really on SymbolicUtils.jl.

Those methods could have had leading underscores to make it really clear they are internals, but they are just to split up fallback setproperties behaviour between tuples and objects as it's different.

They're not documented anywhere as something to rely on.

(But if you PR a satisfactory fix for all it will likely be merged)