This just feels wrong. It's an abstraction on top of JuMP to make two extensions work together. Can we not come up with a way where this just works normally?

what should we do about set_name, set_binary etc?

We could leave it as kwargs... or explicitly have them. I believe only set_name and set_binary are needed for MOAI.

This just feels wrong. It's an abstraction on top of JuMP to make two extensions work together. Can we not come up with a way where this just works normally?

I agree that it would be nice to more naturally have these extensions "just work" together. Here, I believe the core issue is that extensions at the JuMP level do not inherently compose all that well whereas MOI-level ones do.

With all that said, I still would very much like to avoid duplicating much of MOAI to work with InfiniteOpt. This PR may or may not be the right approach. I open to alternative strategies to facilitate the use of JuMP.AbstractVariables, including ones that might require changes to InfiniteOpt. There is no need to rush this.

Here, I believe the core issue is that extensions at the JuMP level do not inherently compose

Yeah. I had mainly thought this applied to extensions that both created different AbstractVariableRef subtypes. It didn't occur to me that it would be a problem for basic @variable usage.

Closing because this is out-of-date, and I don't particularly like it. I'll leave the issue open and we can have another think.