Add Uno solver (unopy) to NLP solver CI workflow

[Transurgeon]

Description

Please include a short summary of the change.
Testing the CI with new unopy release.
See issue here: cvanaret/Uno#485.
Let's wait until they fix it, since it still doesn't seem to work.
Also I had to change the solver to use the IPM method for the geo mean tests.. and Uno still takes over 1000 iterations :(.
Issue link (if applicable):

Type of change

• New feature (backwards compatible)
• New feature (breaking API changes)
• Bug fix
• Other (Documentation, CI, ...)

Contribution checklist

• Add our license to new files.
• Check that your code adheres to our coding style.
• Write unittests.
• Run the unittests and check that they’re passing.
• Run the benchmarks to make sure your change doesn’t introduce a regression.

[github-actions]

Benchmarks that have stayed the same:

   before           after         ratio
 [b75b7cbd]       [65f8dc99]
      231±0ms          241±0ms     1.04  gini_portfolio.Murray.time_compile_problem
      136±0ms          142±0ms     1.04  high_dim_convex_plasticity.ConvexPlasticity.time_compile_problem
      496±0ms          516±0ms     1.04  semidefinite_programming.SemidefiniteProgramming.time_compile_problem
      316±0ms          323±0ms     1.02  gini_portfolio.Yitzhaki.time_compile_problem
      1.02±0s          1.04±0s     1.02  finance.FactorCovarianceModel.time_compile_problem
      4.00±0s          4.06±0s     1.02  huber_regression.HuberRegression.time_compile_problem
      12.7±0s          12.8±0s     1.02  finance.CVaRBenchmark.time_compile_problem
      4.64±0s          4.70±0s     1.01  svm_l1_regularization.SVMWithL1Regularization.time_compile_problem
      21.5±0s          21.7±0s     1.01  sdp_segfault_1132_benchmark.SDPSegfault1132Benchmark.time_compile_problem
      281±0ms          284±0ms     1.01  matrix_stuffing.ParamSmallMatrixStuffing.time_compile_problem
      5.03±0s          5.07±0s     1.01  optimal_advertising.OptimalAdvertising.time_compile_problem
      1.60±0s          1.61±0s     1.00  tv_inpainting.TvInpainting.time_compile_problem
      3.03±0s          3.04±0s     1.00  quantum_hilbert_matrix.QuantumHilbertMatrix.time_compile_problem
      1.40±0s          1.41±0s     1.00  matrix_stuffing.ParamConeMatrixStuffing.time_compile_problem
      689±0ms          689±0ms     1.00  matrix_stuffing.ConeMatrixStuffingBench.time_compile_problem
      283±0ms          282±0ms     1.00  slow_pruning_1668_benchmark.SlowPruningBenchmark.time_compile_problem
     14.6±0ms         14.6±0ms     1.00  simple_LP_benchmarks.SimpleFullyParametrizedLPBenchmark.time_compile_problem
      1.02±0s          1.02±0s     1.00  gini_portfolio.Cajas.time_compile_problem
      240±0ms          239±0ms     1.00  simple_QP_benchmarks.SimpleQPBenchmark.time_compile_problem
      1.83±0s          1.82±0s     0.99  simple_QP_benchmarks.UnconstrainedQP.time_compile_problem
      10.7±0s          10.6±0s     0.99  simple_LP_benchmarks.SimpleLPBenchmark.time_compile_problem
     39.5±0ms         39.0±0ms     0.99  matrix_stuffing.SmallMatrixStuffing.time_compile_problem
     15.4±0ms         15.2±0ms     0.99  simple_QP_benchmarks.ParametrizedQPBenchmark.time_compile_problem
      912±0ms          901±0ms     0.99  simple_LP_benchmarks.SimpleScalarParametrizedLPBenchmark.time_compile_problem
      780±0ms          767±0ms     0.98  simple_QP_benchmarks.LeastSquares.time_compile_problem

[cvanaret]

Hi @Transurgeon,
Could you try to install unopy with pip instead of uv pip, so that we can rule out uv as a culprit?

[Transurgeon]

Hi @Transurgeon, Could you try to install unopy with pip instead of uv pip, so that we can rule out uv as a culprit?

I tried locally and it still doesn't seem to work unfortunately.
The AI says it has something to do with being unable to link to HiGHS.. since there is an ABI mismatch.
I tried uninstalling the homebrew HiGHS, but it also didn't really work.

[cvanaret]

@amontoison do you think it's trying to link some other HiGHS library that exists somewhere else?

[amontoison]

With the latest release of unopy, I do a static linking with all libraries on Mac and Linux.
Are you sure to use the precompiled artifacts?
What is the version of unopy that you are using?

The AI is saying something totally wrong.
I am scared that someone is using -lstdc++ instead of -lc++ but it should only happen with a local build.

[Transurgeon]

With the latest release of unopy, I do a static linking with all libraries on Mac and Linux. Are you sure to use the precompiled artifacts?

yes I believe so.. I think pip automatically tries to get precompiled artifacts.

What is the version of unopy that you are using?

It is installing the latest, which is 0.2.1

The AI is saying something totally wrong. I am scared that someone is using -lstdc++ instead of -lc++ but it should only happen with a local build.

I totally trust you, but it would be nice if you could double check that. Maybe the HiGHS binaries have been built using -lstdc++ by accident?

(DNLP) ➜  DNLP git:(retry-uno-CI) ✗ python -c "import unopy; print('OK')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
    import unopy; print('OK')
    ^^^^^^^^^^^^
ImportError: dlopen(/Users/willizz/Documents/DNLP/.venv/lib/python3.13/site-packages/unopy.cpython-313-darwin.so, 0x0002): symbol not found in flat namespace '__ZN5Highs14setOptionValueERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEPKc'

it seems like part of the string has a cxx which is potentially related to a libstdc++ installation?
Sorry for using the AI for testing this.. I am not familiar with these different ways of making and building wheels.
However, it does seem to be a weird error, since for linux there's no issues at all.

[cvanaret]

@Transurgeon we did have an issue with the wheels workflow for macOS, it compiled with full GNU instead of Clang+gfortran.
It is now fixed in unopy 0.2.2. Can you re-run your workflow?

[Transurgeon]

@Transurgeon we did have an issue with the wheels workflow for macOS, it compiled with full GNU instead of Clang+gfortran. It is now fixed in unopy 0.2.2. Can you re-run your workflow?

it seems to work now, thanks a lot @cvanaret @amontoison !

[cvanaret]

@Transurgeon great :) I'm happy to address the issues with the ipopt preset (many iterations required) in a separate PR.

[amontoison]

Thanks @cvanaret !
I cross-compiled HiGHS and the other dependencies with clang / clang++ so they expected Uno to be linked with libc++ and not libstdc++.
By using gcc / g++ you created an hybrid beast 🙂