[ENH] Review `ecos`, `cvxopt`, `cvxpy` dependencies

[tschm]

Use cvxpy-base and clarabel. The actual solver is an argument to cvxypy's solve attribute of the Problem class. A user can install any solver compatible with cvxpy. For a list see:

https://www.cvxpy.org/tutorial/solvers/index.html

If a user is keen(?) to continue to use ecos (no longer the standard solver for cvxpy) they can install it and instead of solve() call solve("ecos"). Same applies to cvxopt.

[fkiraly]

Yes, I noticed that ecos is not a dependency in essence, but it occurs in some tests and as a default in a method. This default needs to be deprecated, since it is inconsistent with other solver defaults.

Can you kindly explain what you are suggesting regarding cvxpy though? The package seems central.

cvxopt is also a soft dependency.

[tschm]

cvxpy is most crucial. cvxpy is an abstraction layer between solvers (ECOS, clarabel, cvxopt, mosek and many others...) It's an amazing tool as it is today the most gentle route into optimization. One can change the solver by providing the name of it to the solve attribute of the Problem class, e.g. I can work in development with clarabel and change for production to Mosek (commercial solver). To simplify life for most developers cvxpy comes with a bunch of solvers. For many years ECOS was the standard solver for cvxpy. But then clarabel came along. But then there is SCS and a few others. Those solvers never disappoint to provide some deployment fun. Hence, cvxpy-base was introduced. It's a stripped version of cvxpy and comes without any pre-installed solvers. So often users combine cvxpy-base with Mosek or cvxpy-base with clarabel. It should not(!) be the task of pyportfolioopt to manage the zoo of solvers out there.