Initial proof-of-concept for dynamic HiPO loading in highspy

[mathgeekcoder]

This is a quick and nasty proof-of-concept for dynamic loading of HiPO in highspy.

• It adds a new highspy-hipo wheel, which is dependent on highspy
• highspy has an optional dependency on highspy-hipo
• both can be installed via pip install highspy[hipo]

At runtime, highs will dynamically check to see if the highs-hipo.dll (or .so etc.) library is available. If so, it will load the appropriate function pointer address and hook everything up. Otherwise, HiPO is disabled.

It also performs a sanity version check to make sure highspy and highspy-hipo are the same version to prevent issues.

The PATH lookup is a little bit of a hack at the moment.

• It uses environment variables at runtime to share the path
• This environment variable is set by the initializer of highspy-hipo, which is called by is_hipo_available in highspy
• Advanced users can manually set the path to force a different directory (perhaps useful for testing)
• Perhaps we might want to consider alternative options

As it stands, it mostly works. It correctly identifies if the library is installed and makes the appropriate calls. I had some issues with BLAS crashing that I haven't looked into yet.

[mathgeekcoder]

I'm not wanting to push this code. It's more for a reference for @galabovaa

[mathgeekcoder]

Note: this currently might have issues with static variables or thread local storage (e.g., the parallel code) since the highspy-hipo library is currently duplicating the dependent code that is also used in highspy.

The HiPO library can be made dependent on highspy/libhighs (without duplication) - even though highspy/libhighs can dynamically load the HiPO library. It's not quite a circular dependency, but need to take care. I might look at this next week.

[galabovaa]

Thank you, @mathgeekcoder

I opened #2756 just for reference, what I had so far for the highs with hipo wheel and tests of both highspy wheels