Support loading extension in precompiled package

[yuyichao]

The global needs to exist in the base package to avoid the error

Creating a new global in closed module `NLopt` (`Optimizer`) breaks incremental compilation because the side effects will not be permanent.

This only happens if NLopt and MathOptInterface are both loaded during precompilation. It's still unfortunate that the global is not const anymore but this would at least fix the error.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Files	Coverage Δ
src/NLopt.jl	52.43% <ø> (ø)

📢 Thoughts on this report? Let us know!.

[stevengj]

It's still unfortunate that the global is not const anymore but this would at least fix the error.

Is it const if MathOptInterface is loaded? The code still does const Optimizer = NLoptMathOptInterfaceExt.Optimizer in that case, no?

[yuyichao]

No, which branch got executed only depends on Julia version and not on what’s being loaded. At precompile time on a new enough julia version, MOI is never loaded and the constant branch never runs.

[yuyichao]

Alternatively, we could make Optimizer an abstract or parametrized type so that the binding can be constant. I believe the standard use of this is actually only using this as a factory type and there isn't even any requirement that the returned value is an instance of the type passed in (and the input doesn't even need to be a type).

This would only make a difference if NLopt.Optimizer is used outside of JuMP in a way that relies on this being a concrete type and I did find one of such use in the wield with a simple github search https://github.com/OpenMendel/OrdinalMultinomialModels.jl/blob/60bbc53665879b9fb8f2950c602f8444b10e9ad8/src/ordmntest.jl#L138 . It should be trivially fixable but the change could still technically count as breaking.

[odow]

Closing as duplicate of #211