v1.0.5

This version introduces wheels for the aarch64 platform. No functional changes have been introduced wrt v1.0.4.

v1.0.4

This version fixes a bug and adds a feature.

• When using numpy>=2 along with <solver>.setup() without specifying either P or A (i.e. letting the solver infer values for P or A), users would have encountered an AttributeError in numpy. This is now fixed. (Issue 177)

• Certificates of infeasibility prim_inf_cert and dual_inf_cert are now returned as additional attributes of the <solver>.solve() invocation (all previously returned attributes are preserved). This functionality existed in pre-1.0 versions of the osqp python wrappers. (Issue 174)

Thanks @stephane-caron

v1.0.3

This version introduces two useful enums that can be queried to see the status of several solver operations:

osqp.SolverStatus is useful in the case of <solver>.solve().
osqp.SolverError is useful in the case of <solver>.setup(), <solver>.update_settings() or <solver>.solve().

We also introduce a useful exception class, osqp.OSQPException, that can be "equated" to these enums to find its value:

e == osqp.SolverError.OSQP_NONCVX_ERROR

See the examples folder for usage.

There are a couple of behavior changes that users need to be aware of:

• Initially, if <solver>.update_settings() failed (due to incorrect values of parameters or otherwise), it would have failed silently. With this version, it will raise an osqp.OSQPException. This is a breaking change, but we believe that raising an exception is more explicit and useful than failing silently.
• The raise_error parameter in <problem>.solve() still defaults to False, but this has the potential of hide problems if the solve failed, so we might change it to True in the future. For now we simply warn the users of this possible change. Users should always check res.info.status or res.info.status_val in any case.
• The .setup() (and .solve(raise_error=True)) invocations on <solver> would initially have raised ValueErrors. These now raise osqp.OSQPExceptions which are more introspectable.

See Status values and errors for a comprehensive list of status values that you might want to watch out for.

v1.0.1

With this release, we're making available osqp cuda (12.x) and mkl wheels available on PyPI, as osqp-cu12 and osqp-mkl packages respectively, so there is no need to download these specialized "backend algebra" wheels from GitHub.

Users do not need to explicitly pip install these packages, but can choose to install osqp with the correct extras (cu12 or mkl, or both).

pip install osqp[cu12]
pip install osqp[mkl]

More detailed instructions at https://osqp.org/docs/get_started/python.html

v1.0.0

This version of osqp-python is built from tag 1.0.0 of osqp.

Source distributions and binary wheels for builtin algebra are available at PyPI. MKL, CUDA and Wasm32 wheels are available here on Github.

Some minor changes over 1.0.0beta4 include:

• Not storing P/q/A/l/u matrices/vectors in the wrapper object, but passing them straight through to the underlying wrapped C code.
• Not allowing any kwargs on update_settings that we don't recognize.
• Using polishing and warm_starting as setting parameters in wrapper, even tough the old polish and warm_start are also supported for now.
• Added some more examples in the examples/ folder.

v1.0.0b4

This is a the final beta release of osqp-python for the upcoming OSQP v1.0.

Source distributions and binary wheels for builtin algebra are available at PyPI. MKL, CUDA and Wasm32 wheels are available here on Github.

v0.6.7.post1

This version of OSQP does not insist that the version of scipy!=1.12.0 as a runtime dependency (which v0.6.7.post0 enforced).

While scipy 1.12.0 does cause certain test results in development to fail (because of a transient behavior change in scipy), this is a developer-facing issue, and this dependency constraint is not enforced upon users of osqp-python.

v0.6.7.post0

• Support NumPy 2.0 for Python 3.9+