Provide conda-forge package for osqp-eigen

[GiulioRomualdi]

osqp-eigen can be now easily installed using coda

conda install -c robotology osqp-eigen

Since osqp (please check here) is already provided in conda-forge and osqp-eigen is not only used by the robotology community, I think it makes sense to move the receipt in conda-forge.

cc @traversaro

[traversaro]

Good idea! The more conda packages we move from the robotology-superbuild to conda-forge, the easier is to mantain the packages that it remains (for example, in robotology/robotology-superbuild#749 the conda package generation pipeline take 4 hours, making debug not obvious).

Things to do:

• Before submitting the recipe, we need to decide on an ABI policy for osqp-eigen, as this will specify the run_exports details (see https://github.com/conda-forge/open62541-feedstock/blob/a2802d62baa05b191fe469abb5df5311cfed64af/recipe/meta.yaml#L15). If we think we may break ABI at each new patch release, we should just put pin_subpackage(name, max_pin='x.x.x') }}
• Once the package is accepted in conda-forge, we should set the OsqpEigen_CONDA_PKG_CONDA_FORGE_OVERRIDE option in the BuildOsqpEigen.cmake file in the superbuild, as explained in https://github.com/robotology/robotology-superbuild/blob/fc1cd88248069eb637f567357497145681b3fd68/doc/developers-faqs.md#how-to-ensure-that-binary-packages-are-correctly-generated-for-a-new-package .

[traversaro]

Since osqp (please check here) is already provided in conda-forge and osqp-eigen is not only used by the robotology community, I think it makes sense to move the receipt in conda-forge.

One small comment: osqp is the Python package, the C package is libosqp (https://github.com/conda-forge/libosqp-feedstock).

[GiulioRomualdi]

• Before submitting the recipe, we need to decide on an ABI policy for osqp-eigen, as this will specify the run_exports details (see https://github.com/conda-forge/open62541-feedstock/blob/a2802d62baa05b191fe469abb5df5311cfed64af/recipe/meta.yaml#L15). If we think we may break ABI at each new patch release, we should just put pin_subpackage(name, max_pin='x.x.x') }}

I just checked the semantic versioning specification and there seems no mention on ABI. Here they suggest changing the major version even if the ABI are broken.

So in conclusion we can release 1.0.0 and apply the following rule

1. Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.
2. Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.
3. Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.
4. Major version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to the public API and ABI. It MAY also include minor and patch level changes. Patch and minor version MUST be reset to 0 when major version is incremented.

I would also add a CI that varifies that ABI are preserved (e.g https://lvc.github.io/abi-compliance-checker/)

Off-topic: Please click here if you want to know more about abi breaking changes.

[traversaro]

Apparently moving this to conda-forge may be a good idea indeed, as osqp-eigen is start being used as a dependency in project outside of robotology that are being packaged in conda as well, see tesseract-robotics/tesseract#419 .

[traversaro]

I would also add a CI that varifies that ABI are preserved (e.g https://lvc.github.io/abi-compliance-checker/)

Note that for now for simplicify we can just start to just assume that ABI is broken at each patch release (as it happens in many libraries even widely used in robotics, see for example OpenCV https://github.com/conda-forge/opencv-feedstock/blob/246ffa4db0ca7348e9f3e7c20994aacedcdb8ba1/recipe/meta.yaml#L51 or boost https://github.com/conda-forge/pcl-feedstock/blob/master/recipe/meta.yaml#L44 ). Don't get me wrong, ABI stability is quite convenient especially if osqp-eigen starts get used in a lot of projects to avoid frequency ABI migrations (see https://conda-forge.org/blog/posts/2019-12-06-cfep09/ and https://github.com/conda-forge/cfep/blob/master/cfep-09.md), but I don't think this should stop from packaging osqp-eigen in conda-forge. On that, for me it is quite easy to propose a new recipe in staged-recipes, if you want i can go on and add you as mantainer, otherwise if you prefer to do it yourself please do when you prefer.

[GiulioRomualdi]

Associated issue conda-forge/staged-recipes#15080

[GiulioRomualdi]

Related PR: conda-forge/staged-recipes#15309