Closed h-vetinari closed 1 year ago
Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe
) and found it was in an excellent condition.
@conda-forge-admin please rerender
If you want we can separate this PR from the switch to libosqp, which is trickier than just a version bump
Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe
) and found it was in an excellent condition.
Hey @conda-forge/osqp @conda-forge/libosqp
After being open for more than 2.5 years (xref #25), I've finally figured out how to build osqp against our existing shared library build of the C-side, libosqp
(which contains libosqp.so
/ libosqp.dylib
/ osqp.dll
etc. per platform).
That would finally bring this feedstock in line with conda-forge best practices, reduce the package footprint, and bring several other benefits.
However, this comes at the cost of having to deactivate the codegen ability of osqp
. Basically:
osqp
package, so that it can be copied and compiled into a standalone library when needed.EMBEDDED
symbol being defined, and has a different ABI than what the code generation here requires.
status_polish
, which is required by the libosqp type when EMBEDDED
is not defined, see herelibosqp
for the main library, but keeping the source files as "data" in site-packages, copying them for codegen and running the result), I ran into segfaults (CI), due to namespace, symbol & ABI clashes about which library the python side of osqp
is passing its values to, so this too fell on its face.To recap the available options:
libosqp
is possible, but:
libosqp
is compiled non-EMBEDDED
$SP_DIR/osqp/codegen/sources
is also possible, but:
libosqp
with the EMBEDDED
ABI (there are three different ones actually!) is not reasonableSo I'm planning to disable codegen here (see the last patch), and wanted to ask if there are objections, alternatives I overlooked, or other thoughts about this.
CC @conda-forge/cvxpy @conda-forge/libqdldl @conda-forge/qdldl-python @vineetbansal @imciner2
I think it is reasonable to disable codegen. If codegen is needed, one can always install the osqp wheels from PyPI in a conda environment.
~Upstream has been pushing new versions (0.7.x) that the bot seems to have missed.~
Edit: as it turns out, these were not meant for publication anyway.
Edit²: Split off the version bump into #49, now just doing the switch to conda-forge's libosqp
Closes #37 Closes #36 Closes #35 Xref #25