Hi, I am currently testing this PR by running: python examples/pyomo/columngeneration/cutting_stock.py gurobi_persistent
It seems that my change calls gurobipy.Model before the deferred import are resolved, has anybody encountered this kind of error before ? I don't think it's related to my installation setup as the main branch runs fine.

File "d:\dev\pyomo\pyomo\solvers\plugins\solvers\GUROBI.py", line 38, in
from .gurobi_direct import gurobipy_available
File "d:\dev\pyomo\pyomo\solvers\plugins\solvers\gurobi_direct.py", line 100, in
class GurobiModel(gurobipy.Model):
File "d:\dev\pyomo\pyomo\common\dependencies.py", line 170, in getattr
return getattr(_mod, attr)
File "d:\dev\pyomo\pyomo\common\dependencies.py", line 77, in getattr
raise DeferredImportError(self._moduleunavailable_message())
pyomo.common.errors.DeferredImportError: The gurobipy module (an optional Pyomo dependency) failed to import: NameError: name 'GurobiDirect' is not defined

Hi, I am currently testing this PR by running: python examples/pyomo/columngeneration/cutting_stock.py gurobi_persistent It seems that my change calls gurobipy.Model before the deferred import are resolved, has anybody encountered this kind of error before ? I don't think it's related to my installation setup as the main branch runs fine.

Yes - the problem is your definition of the GurobiModel class:

class GurobiModel(gurobipy.Model):

Parsing / compiling this definition (during module import) accesses the Model attribute on the gurobipy object (at this point, it is a DeferredImportModule object and not the gurobipy module). That attribute access triggers the deferred import system to attempt the import, which will fail if gurobipy is not actually available.

The simplest "workaround" might be something like:

class GurobiModel(gurobipy.Model if gurobipy_available else object):

However, that will run afoul of another test in the Pyomo unittest system: this solution still triggers the gurobipy import - when you implicitly cast gurobipy_available to a bool as part of the if. Because this module gets imported as part of pyomo.environ, this would force the import of gurobipy as part of pyomo.environ - and we have a test that checks that optional dependencies are not automatically imported by pyomo.environ.

The better solution is probably to define an _addConstr private method on the GurobiDirect class instead of defining a "wrapper" model class.

Thank you so much for your help @jsiirola, I have implemented your suggestion, and it works great!

@quantresearch1 I removed the [WIP] marking from the title to check the test status on this PR. Is this ready for review or still work in progress?

@blnicho thanks, let me fix the unit tests first before asking for a review

@blnicho I think I have fixed it. The issue was that for NumericConstant expression, the degree is 0. I would incorrectly raise a DegreeError as I was expecting _get_expr_from_pyomo_repn to only give me degrees 1 or 2

@jsiirola The win/3.9 build failed with a segmentation in conda, should I just give the CI another run ? Sorry I am not sure how to debug this issue.

Platform: win-64
Collecting package metadata (repodata.json): ...working... done
/c/Users/runneradmin/.bash_profile: line 347: 781 Segmentation fault ( "$CONDA_EXE" $_CE_M $_CE_CONDA "$@" )
Solving environment: ...working...
Error: Process completed with exit code 139

@quantresearch1: the windows failure is an issue with conda that crops up with surprising regularity (the error is happening while trying to set up the conda environment and has nothing to do with Pyomo). Usually waiting a couple hours and re-running that job will clear it.

Great to see all checks are now passing. May I merge it ?