[Xpress] Remove deprecation warnings (#1)

[XPRSc4v4]

Hi!

Fixes

• Deprecated function names in Xpress 9.8+ (Python API v46)
• Removed enums in Xpress 9.8+
• Compatibility with both pre-9.8 and post-9.8 Xpress versions

Summary/Motivation:

Starting with Xpress 9.8 (Python API version 46), FICO deprecated lowercase function names in favor of camelCase (e.g., lpoptimize → lpOptimize) and removed several enum types. The old functions are still available but deprecated, and will be removed in future releases. This PR adds runtime version detection to dispatch to the correct functions and enums based on the installed Xpress version, eliminating deprecation warnings while maintaining backward compatibility.

Changes proposed in this PR:

• Extended version detection logic that checks Xpress Python API version at runtime
• Created compatibility wrappers that dispatch to correct function names (lowercase for v45-, camelCase for v46+)
• Updated enum handling to use new attribute access pattern for v46+ while maintaining old enum values for earlier versions
• Modified tests to use XpressDirect interface instead of calling Xpress Python APIs directly
• All changes maintain full backward compatibility with Xpress versions prior to 9.8

Legal Acknowledgement

By contributing to this software project, I have read the contribution guide and agree to the following terms and conditions for my contribution:

1. I agree my contributions are submitted under the BSD license.
2. I represent I am authorized to make the contributions and grant the license. If my employer has rights to intellectual property that includes these contributions, I represent that I have received permission to make contributions and grant the required license on behalf of that employer.

[codecov]

Codecov Report

❌ Patch coverage is 91.03448% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.47%. Comparing base (f2d23a5) to head (2121e59).

Files with missing lines	Patch %	Lines
pyomo/solvers/plugins/solvers/xpress_direct.py	90.84%	13 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3794      +/-   ##
==========================================
- Coverage   89.48%   89.47%   -0.01%     
==========================================
  Files         904      904              
  Lines      105385   105474      +89     
==========================================
+ Hits        94299    94377      +78     
- Misses      11086    11097      +11     

Flag	Coverage Δ
builders	29.05% <36.55%> (+0.01%)	⬆️
default	83.57% <71.72%> (?)
expensive	35.54% <36.55%> (?)
linux	86.73% <57.24%> (-2.48%)	⬇️
linux_other	86.73% <57.24%> (-0.03%)	⬇️
oldsolvers	29.73% <56.55%> (+0.04%)	⬆️
osx	82.88% <57.24%> (-0.03%)	⬇️
win	84.96% <57.24%> (-0.05%)	⬇️
win_other	84.96% <57.24%> (-0.05%)	⬇️
xpress95	33.77% <37.24%> (-49.25%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[blnicho]

This is changing the xpress version for every GHA job using conda to install Python packages which is not what I think you intended. During the dev call we talked about installing an older version of xpress on just one or two jobs to exercise the version-specific logic in the solver interface. I think you can do this by modifying the if-tree above that sets the XPRESS environment variable. There is already some special logic there for windows so maybe we use the linux conda job for this. I think you can just modify the else section on line 450 to something like:

if test "${{matrix.TARGET}}" == linux; then
    XPRESS='xpress<9.3'
else
    XPRESS='xpress'
fi

[XPRSc4v4]

Sorry, I should have asked for clarification during the call!
I've applied the changes, targeting Python 3.10 so the latest Xpress release is still tested in the other jobs. Let me know if there are any other issues.

[blnicho]

So turns out we can't use the Linux conda job to test an older version of Xpress because we can't get ANY version of Xpress to install in our Linux/conda GHA job. I tried both Python 3.11 and 3.12. They fail saying the environment can't be satisfied because intel-openmp can't be found in our conda channels. I modified the workflow to try using the win/3.10 and win/3.11 jobs instead.

[XPRSc4v4]

Thank you, Bethany. Let me know if there is anything I could do to help!

[blnicho]

Our conda environments are fragile on GHA so I switched to using the linux/3.10 and linux/3.11 jobs for this which install Xpress using pip. I'll mark this discussion as resolved once I verify that the right versions of Xpress were installed.

[blnicho]

@XPRSc4v4 unfortunately, I don't think there is a way to test an "old enough" version of Xpress to cover the version-based if-tree in the interface using our GHA infrastructure. Asking for xpress<9.3 in the linux pip jobs did install an old version of Xpress but it was unusable because other packages required Numpy 2 which I think led to an inconsistent environment where Xpress was installed but not importable/available. Correct me if I'm wrong, but the first version of Xpress to support Numpy 2 was 9.6 which I think uses the same Python API as 9.8 and thus won't exercise a different portion of the if-tree. Given limited testing resources, I don't think it makes sense to pin one of our jobs to Numpy 1 just to get a sufficiently old version of Xpress.

If you agree with my assessment then I think we should revert the changes to the GHA workflow and accept the slight decrease in coverage.

[XPRSc4v4]

I agree, it would have been nice to have coverage for those compatibility branches, but not at the expense of complicating the test environment. The slight decrease in coverage is fine. Thanks for looking into this!

[jsiirola]

Overall this seems OK. I do have one suggestion that might simplify things (wrap the Xpress model class instead of adding a bunch of private dynamic functions on the Pyomo solver interface):

[jsiirola]

Instead of creating all these function pointers for both old and new Xpress, would it be simpler and more clear to create an Xpress45Problem wrapper class that would wrap an old-style problem instance and support both the old-style and new-style interfaces? Something like:

class Xpress45Problem:
    def __init__(self, prob):
        super().__setattr__(self, '_wrapped_problem', prob)

    def __getattr__(self, name):
        # The new API is camelCase, whereas the old interface was
        # all lowercase: try the new API and fall back on all lowercase:
        try:
            return getattr(self._wrapped_problem, name)
        except AttributeError:
            return getattr(self._wrapped_problem, name.lower())

    def __setattr__(self, name, val):
        return setattr(self._wrapped_problem, name, val)
        'setLogFile': 'setlogfile',
        'lpOptimize'

[blnicho]

@XPRSc4v4 we added a new Jenkins build that tests the old Xpress interface so we can get the test coverage we wanted. Could you address the review comment from @jsiirola and then we can get this merged?