I just spent a little time trying to see what it would take to allow ilpy to be installed and run without all backends being present in the environment. (Currently, one must install all possible backends for ilpy to even import, even if they only intend on using one)
The thing that would need to change, I believe, is the SolverFactory. Currently SolverFactory.cpp includes all of the headers that are present at build time, (and expects them all to be there at runtime), which would necessitate a different build for every backend/combination.
If we pulled out the SolverFactory.createXSolverBackend logic from cpp land and put it into python, then we could try/except any specified backend preferences, meaning if scip or gurobi wasn't installed, it would simply raise a runtime python exception (at the moment of unsatisfiable preference) rather than an ilpy ImportError.
I just spent a little time trying to see what it would take to allow ilpy to be installed and run without all backends being present in the environment. (Currently, one must install all possible backends for ilpy to even import, even if they only intend on using one)
The thing that would need to change, I believe, is the
SolverFactory. CurrentlySolverFactory.cppincludes all of the headers that are present at build time, (and expects them all to be there at runtime), which would necessitate a different build for every backend/combination.If we pulled out the
SolverFactory.createXSolverBackendlogic from cpp land and put it into python, then we could try/except any specified backend preferences, meaning if scip or gurobi wasn't installed, it would simply raise a runtime python exception (at the moment of unsatisfiable preference) rather than an ilpy ImportError.