quadprog wheel package about qpsolvers

[stephane-caron]

Thank you for bringing this up 👍 I hadn't realized how compiling quadprog was a problem for some users.

I hope the quadprog maintainers can find some time to review quadprog/quadprog#31, as they seem open to the idea of distributing wheels.

In the meantime, no problem to guide users from qpsolvers' side as well:

Would it be possible for qpsolvers to provide the ability to (optionally?) install quadprog-wheel instead of quadprog?

Sure, we can add:

[project.optional-dependencies]
quadprog_wheel = [
    "quadprog-wheel >=0.1.11",
]

Then users could install qpsolvers and quadprog-wheel at once by pip3 install "qpsolvers[quadprog_wheel]".

But then...

I guess the main issue lies with the default dependencies, which have been so far:

[project]
dependencies = [
    "quadprog >=0.1.8",
    "scipy >=1.2.0",
]

The goal was to have qpsolvers come "batteries included" with at least one solver, so that newcomers can call solve_qp without wondering what solver to use at first. Now this choice bites back as a change of default solver is a breaking change.

Enumerating out loud the options I see from there:

1. Switch the default solver to osqp or scs, which come with pre-compiled wheels
   • Pro: easier behavior for new users
   • Con: silently changes performance (potentially drastically) of existing code
2. Have no default solver
   • Pro: no ambiguity as to what solver is used
   • Con: API-breaking change (would take us to qpsolvers 2.0.0)
   • Con: one more step for beginners
3. Keep the solver="quadprog" default, switch default dependency to quadprog-wheel:
   • Pro: non-breaking change for qpsolvers
   • Con: potential confusion arising from the two PyPI packages, hopefully the split is resolved with the quadprog project getting pre-compiled wheels (separate from this issue, I'll also loop in there)

Chime in if you see others options!

I feel option 2 (no default solver, change API) is the best one, as we can guide both beginners and existing users through the change with a proper exception message.

[AntoineD]

For my PR to the quadprog project, I have no hope anymore after having pinged them so many times since last year ... to no avail.

Unfortunately it seems to me that if quadprog remains a mandatory dependency, its package will fail to be built even though the optional quadprog-wheel is asked for.

[stephane-caron]

I've prepared #63, @AntoineD would you agree to review it so that it gets a second pair of 👀?

[AntoineD]

Awesome! I'll look at it by the end of the week.