-
Notifications
You must be signed in to change notification settings - Fork 220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compat issue #2251
Comments
Doesn't help but IMO it's pretty annoying that SciML packages bumped the Julia compat in this way (even though many packages would still work, sometimes with minor modifications, on older Julia versions). Turing is not the first project where this causes problems. The ADTypes updates also broke many packages due to incorrect compat entries...
So it seems we could just use subtypes of Generally, could we move the Optimization code to an extension (dependent on SciMLBase?), similar to the Optim extension? Then we would be a bit less affected by incompatibilities with the SciML ecosystem and (possibly) pull in fewer SciML dependencies. |
Yeah all of this is annoying 😕
IMO the way to go to fix this asap. The only reason why we bumped this was because #2236 wanted Tapir.jl to be explicitly exported from Turing.jl (which seems somewhat premature IMO). @yebai Can we drop export of Tapir.jl? It will still be available for users who want to use it through |
Part of the motivation to move over to Optimization.jl was to not have to make all these extensions 😕 That way, we could get the benefit of all the different optimization packages through Optimization.jl, e.g. eventually drop the extension for Optim.jl. |
It would just be a single extension on SciMLBase or Optimization, which would still allow Turing to benefit from all different optimization packages through Optimization. In particular, since apart from some core default optimization functionality users have to load the respective backend anyway it seems fine (i.e., without impacting usability) to move the Optimization.jl functionality to an extension. (BTW there is also a more lightweight OptimizationBase.jl which could be an alternative to SciMLBase for an extension.) |
Ah gotcha; yeah that I'm happy with:) |
I am happy to export Note that |
Also, I am not sure moving stuff to extensions would help avoid dependency conflicts: doesn't Julia require all weakdeps to also have compat entries? |
It does, but the (possible) advantage would be that by default SciMLBase/OptimizationBase/Optimization would not be installed when installing Turing, so any conflicts with (dependencies of) SciMLBase/OptimizationBase/Optimization would not matter for users that do not want to use the Optimization-dependent features of Turing. |
Oh okay then we should definitively do that 👍 |
So is the idea to reintroduce compat with ADTypes v0.2 and then have something like
? |
I have no strong opinion on whether the optimisation stuff should be an extension, I'm not yet familiar with how extensions are typically used. It would change our interface a bit though, in that currently we can export |
It looks good -- I'd also add a check on Julia's version. You can also do
EDIT: the one below might be better since it avoids calling the depreciated using Compat
using ADTypes
@static if VERSION >= v"1.10" && pkgversion(ADTypes) >= v"1"
export AutoTapir
end |
Fixed by #2252 |
We have a problem with ADType/SciMLBase versions in #2237 where some tests are failing on Julia 1.7. I'll try to summarise my understanding of it below. This is partially to clarify my own thoughts, excuse me if this is a bit hard to follow, hopefully you can skip some of the details.
OptimizationFunction
type from SciMLBase. One of its constructor arguments is anAbstractADType
.ADType.AbstractADType
only from its v1.92.1 onwards, at v1.92.0 they still define their ownAbstractADType
. Until then they also had no compat entry for ADTypes.So when installing on Julia 1.7
OptimizationFunction
.I'm not quite sure what to do about this. Can we restore support for ADTypes v0.2, which would then allow e.g. SciMLBase v1.95, and we would be fine? Or could we drop support for Julia <1.9? Something else?
The text was updated successfully, but these errors were encountered: