-
Notifications
You must be signed in to change notification settings - Fork 87
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
Shall we move part of Ipopt's MOI wrapper to a new MOI Utilities? #1169
Comments
I agree the code duplication isn't great, but we also have to be careful that any solution doesn't actually make the solver wrappers harder to read. Writing and reading MOI wrappers is already complex enough. We learned from LinQuadOptInterface that intermediate abstractions can make the wrappers harder to understand because they don't fully alleviate the need for working at the MOI level, so the wrapper has to deal with MOI and the intermediate level at the same time.
What maintenance issues have been tied to borrowing the structure of Ipopt's MOI wrapper? I don't think any changes to the structure have been needed in the past two years. |
I understand. The argument against intermediate abstractions is a good one. |
💯 I'm vetoing intermediate abstractions. |
The large amount of copy-paste should be resolved by #846. |
Closing this issue in favor of #846 |
Reading this new PR: jump-dev/NLopt.jl#150
it looks like several packages are re-implementing Ipopt's MOI wrapper. A non-exhaustive list being
I am wondering if at some point, it would make sense to implement the common parts of these different wrappers as a MOI
Utilities
(e.g. the part to plug the linear and quadratic expressions in theMOI.AbstractNLPEvaluator
)? I think in the long term that would ease the maintenance of the aforementioned packages.The text was updated successfully, but these errors were encountered: