search

sagemath / sage

Main repository of SageMath. Now open for Issues and Pull Requests.
https://www.sagemath.org
Other
1.19k stars 411 forks source link

Meta-ticket: Use Python optimization interfaces: CVXPY, SCIP, or-tools, PuLP, Pyomo, cylp... #26511

Open mkoeppe opened 5 years ago

mkoeppe commented 5 years ago

The purpose of this ticket is to

SageMath status quo: Front end

SageMath status quo: Back ends

SageMath tickets and tasks

Related:

Key Python software (solver-independent)

Selection criteria for solver-independent interfaces:

cvxpy - Meta-ticket #33920

or-tools - #33493

conv_opt - https://github.com/KarrLab/conv_opt

PuLP - https://github.com/coin-or/pulp

Pyomo

YAPOSIB - Python interface to COIN OSI, using Boost::Python

Python MIP (Mixed-Integer Linear Programming) Tools (new 2018)

PICOS - a user friendly Python API to several conic and integer programming solvers, very much like YALMIP or CVX under MATLAB.

PAO

C, C++ solver abstractions

or-tools (#33493) ​linear_solver wrapper

COIN-OR OSI

Key Python software (solver-dependent)

The Python interfaces that target only one solver are usually careful in not having more restrictive licenses than the targeted solver.

scipy.optimize (vendors HiGHS)

highspy (pybind11-based interface to HiGHS)

Interfaces to GLPK

cylp

cbcpy (LGPL; new August 2019 according to ​https://pypi.org/project/cbcpy/; no activity since then)

Gurobi, CPLEX

python-qsoptex

SCIP, PySCIPOpt (now open source)

Possible integration routes via Julia

CC: a.mason@auckland.ac.nz @jiawei-wang-ucd @yuan-zhou @dimpase @dcoudert @sagetrac-tmonteil @kiwifb

Component: numerical

Issue created by migration from https://trac.sagemath.org/ticket/26511

mkoeppe commented 2 years ago
comment:52

Replying to @tkralphs:

thereby taking away freedom

That's what COIN-OR did to users of python-mip by imposing the copyleft EPL license on it, replacing the previous permissive license -- which is the actual problem that I pointed out in comment:34 (and our email exchange in 2021).

mkoeppe commented 2 years ago
comment:53

Replying to @tkralphs:

Why not use the LGPL?

In the case of Sage, obviously because of Wolfram, MapleSoft, and MathWorks.

mkoeppe commented 2 years ago
comment:54

Replying to @tkralphs:

the intention of the license is broader

Sure, maybe, but that's not how it works. [...] But it is all a matter of opinion and the only opinion that really matters is judge and jury.

Sorry, Ted, this is all just wildly misguided.

The authors of software choose GPL as the license because they agree with the widely understood intended interpretation, in particular the strong protections that the GPL intends to provide.

Whether the implementation by the license text holds up legally, is a secondary matter; the license is, so to say, merely an implementation detail.

What matters for the open source / free software community is to respect the intent of the authors, as expressed by their choice of license. Saying that their choices are somehow not legitimate because the license is not legally enforceable, or to discuss circumvention techniques based on narrow interpretations of what linking is, all seems pretty out of place.

dimpase commented 2 years ago
comment:55

Replying to @tkralphs:

Sorry, but I can't help ranting a bit more about the GPL :-).

the intention of the license is broader

Sure, maybe, but that's not how it works. You can't take a vague and (what looks to me to be) unenforceable license

It's sad to see how well shameless anti-GPL propaganda works. GPL violations have been successfully enforced by US courts - as copyright violations (cf. Jacobsen v. Katzer), and even as contract violations (Artifex v. Hancom).

tkralphs commented 2 years ago
comment:56

I am sorry, I didn't intend to offend anyone or spout what sounded like propaganda in a public forum. Since I have known Matthias IRL for many years and have deep respect for him and his work, I let my guard down a bit and probably wasn't careful enough in what I said. I can see how some of what I said could be interpreted as misguided and I apologize for that. However, there is a discussion worth having here if cooler heads can prevail and I think some of what I said was misconstrued. I am open to listening and moderating my point of view and would appreciate the chance to further engage, so consider this an open invitation to have a more in-depth discussion in another appropriate forum. I believe we are all reasonable people who all have valid points of view and can have a rational discourse on this complicated, nuanced topic.

I certainly didn't mean to promote undermining or circumventing the intents of individual rights-holders, which should be respected, and I also didn't mean to denigrate anyone's individual choices or characterize them as illegitimate. I'm a passionate open source developer myself and have tried to do my own independent thinking about these issues over years of working with open source licenses. Yes, my views are biased by the frustration of seeing potential projects that seem to be an obvious "good thing" for the world and that I can't see as objectionable to any of the individual rights-holder stopped in their tracks by this license madness. I am frustrated by the divisiveness and the political agendas. I don't assume the FSF speaks for all those who adopt the GPL and would prefer to directly engage with the rights-holders of any code I intend to work with to understand their point of view and intents.

As a devoted open source developer over more than two decades, my only agenda is enabling people to benefit from the free software I'm contributing to and to grow the community of engaged developers. It would be a win for COIN-OR to be able to partner with Sage. So naturally, I'm looking for a way through this license maze that will allow us to do good work together, of course without undermining the intents of any fellow open source developers. This particular scenario in which the goal is to use an EPL'd code to provide additional functionality within an overall GPL'd code seems harmless to me. The prohibition of this by the linking restriction seems like collateral damage more than something that is by design.

That's what COIN-OR did to users of python-mip by imposing the copyleft EPL license on it, replacing the previous permissive license -- which is the actual problem that I pointed out in comment:34 (and our email exchange in 2021).

I did want to clarify that COIN-OR projects can use any OSI-approved license, including the GPL. Nothing has been imposed. Most have chosen the EPL, following IBM's original lead. Of course, this is partly because it is just easier in terms of license compatibility, but forcing the EPL on people is not the goal, it is just unfortunate side effect that looks to me like it derives from the GPL's prohibition against mixing licenses. The GPL and the EPL actually seem pretty similar in broad philosophy, the big difference being that the EPL is less restrictive on mixing packages under different licenses (yes, I know there are other differences that people view as important).

I will avoid building software on top of brittle interpretations such as the one that you are trying to give in order to arrive at the desired result.

This encapsulates my frustration. Because of the threat of legal action by the FSF, developers with good intentions choose to avoid doing things that actually seem to make sense and that (I don't think) violate anyone else's intent. The FSF seems to want to strong-arm everyone into switching to the GPL. This just makes me bristle. I understand that it is exactly the threat of legal action that gives the GPL its strong protection, but I think there are better ways of going about this that would not be so divisive or result in so much collateral damage.

There's a lot more to be said, but this is obviously not the right place to do it. The invitation to further discussion is open. I hope someone takes me up on it.

mkoeppe commented 2 years ago
comment:57

Replying to @tkralphs:

I did want to clarify that COIN-OR projects can use any OSI-approved license, including the GPL. Nothing has been imposed.

But COIN-OR's embrace of python-mip has prompted the license change.

The old license was a standard permissive license that was compatible with everything: with EPL, with GPL, anything.

Most have chosen the EPL, following IBM's original lead. Of course, this is partly because it is just easier in terms of license compatibility

Yeah, no. This is the core of the damaging misinformation that is coming from the direction of COIN-OR.

unfortunate side effect that looks to me like it derives from the GPL's prohibition against mixing licenses.

No such thing, it is just specifically incompatible with EPL (without secondary license notice), for a specific technical reason.

GPL is compatible with a wide range of licenses, in particular all the standard permissive licenses (MIT, BSD, Apache, ...).

mkoeppe commented 2 years ago
comment:58

Replying to @tkralphs:

I don't assume the FSF speaks for all those who adopt the GPL and would prefer to directly engage with the rights-holders of any code I intend to work with

Yes, it makes no sense to bring up the FSF at all. They published the license; they are not the copyright holder in any software that we are talking about.

mkoeppe commented 2 years ago
comment:59

Replying to @tkralphs:

This particular scenario in which the goal is to use an EPL'd code to provide additional functionality within an overall GPL'd code seems harmless to me.

Yes, which is why we've had no problem in packaging CBC as an optional package that replaces the default solver backend with a better one. And there's also no problem in doing the same with CyLP (#33487).

The situation with python-mip is different, as I explained in comment:38: I was looking into adopting its API as the basis for our interface development, with the goal of using it for several backends. This intended closer integration is no-go with the incompatible license, so it is not going to happen.

mkoeppe commented 2 years ago
comment:60

Ted, I of course appreciate all the hard work and dedication that you have put in maintaining COIN-OR, which among other things preserves CBC, an important open source jewel. CBC/CLP/...'s license incompatibility with the wide range of GPL software is a sad fact regarding this legacy code, for which there is unfortunately no solution.

But COIN-OR would be well-advised to stop spreading this problem to new code.

mkoeppe commented 2 years ago

Description changed:

--- 
+++ 
@@ -44,6 +44,8 @@
 **cvxpy** - #31962
 - use CBC via **cylp**
 - experimental CBC interface via **python-mip** - https://github.com/cvxpy/cvxpy/issues/1265, https://pypi.org/project/mip-cvxpy/
+
+**or-tools** - #33493

 **PuLP**
 - https://github.com/coin-or/pulp
mkoeppe commented 2 years ago

Description changed:

--- 
+++ 
@@ -76,8 +76,7 @@
 **Python MIP (Mixed-Integer Linear Programming) Tools** (new 2018)
 - https://pypi.org/project/mip/
 - https://github.com/coin-or/python-mip
-- Eclipse Public License 2.0 (considered **GPL**-incompatible https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses)
-- **requires Python 3.5 or newer**
+- Eclipse Public License 2.0 (considered **GPL-incompatible** https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses)

 **PICOS** - a user friendly Python API to several conic and integer programming solvers, very much like YALMIP or
 CVX under MATLAB.
mkoeppe commented 2 years ago

Description changed:

--- 
+++ 
@@ -1,19 +1,23 @@
 The purpose of this ticket is to 
-- connect [SageMath](../wiki/SageMath) to interfaces to optimization solvers that are maintained outside of the Sage project,
+- connect SageMath to interfaces to optimization solvers that are maintained outside of the Sage project,
 - integrate the related developer and user communities.

 **Status quo in Sage:**
-- Frontend class `MixedIntegerLinearProgram`
+- Frontend class [MixedIntegerLinearProgram](https://doc.sagemath.org/html/en/reference/numerical/sage/numerical/mip.html#sage.numerical.mip.MixedIntegerLinearProgram)
     - mutable (can call `add_constraint`, `set_integer`, `new_variable` etc. and then re-solve)
-    - solver-independent and solver-specific parameters (solver_parameter)
-    - widely used in Sage code
-    - `MIPVariable` - indexed by arbitrary objects
-    - some connections to Polyhedron class and to InteractiveLPProblem (didactical code)
-- Backends, using Cython, with varying degrees of implementation quality
+    - solver-independent and solver-specific parameters (`solver_parameter`)
+    - widely used in Sage library code for `sage.graphs`, `sage.coding`, `sage.combinat`, ...
+    - [MIPVariable](https://doc.sagemath.org/html/en/reference/numerical/sage/numerical/mip.html#sage.numerical.mip.MIPVariable) - indexed by arbitrary objects
+    - some connections to [Polyhedron](https://doc.sagemath.org/html/en/reference/discrete_geometry/index.html#polyhedral-computations) class and to [InteractiveLPProblem](https://doc.sagemath.org/html/en/reference/numerical/sage/numerical/interactive_simplex_method.html) (didactical code)
+- [In-tree backends](https://github.com/sagemath/sage-prod/tree/develop/src/sage/numerical/backends), using Cython, with varying degrees of implementation quality
     - GLPK backend - complete, includes support for tableau data and GLPK's exact rational mode
-    - COIN backend - very basic, no support for setting solver parameters such as time limit
-    - CPLEX backend, Gurobi backend, CVXOPT backend, PPL backend
     - InteractiveLP backend - basic, provide LP only for algebraic LPs
+    - CVXOPT backend
+    - PPL backend - exact solver
+- Separate distribution packages for optional packages (proprietary solvers, open-source solvers with incompatible licenses)
+    - https://github.com/sagemath/sage-numerical-backends-coin: COIN backend (CBC) - very basic, no support for setting solver parameters such as time limit
+    - https://github.com/sagemath/sage-numerical-backends-cplex: CPLEX backend
+    - https://github.com/sagemath/sage-numerical-backends-gurobi: Gurobi backend
 - Very small developer community

 **Tickets:**
@@ -76,7 +80,8 @@
 **Python MIP (Mixed-Integer Linear Programming) Tools** (new 2018)
 - https://pypi.org/project/mip/
 - https://github.com/coin-or/python-mip
-- Eclipse Public License 2.0 (considered **GPL-incompatible** https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses)
+- Eclipse Public License 2.0 (considered **GPL**-incompatible https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses)
+- **requires Python 3.5 or newer**

 **PICOS** - a user friendly Python API to several conic and integer programming solvers, very much like YALMIP or
 CVX under MATLAB.
mkoeppe commented 2 years ago

Description changed:

--- 
+++ 
@@ -80,8 +80,7 @@
 **Python MIP (Mixed-Integer Linear Programming) Tools** (new 2018)
 - https://pypi.org/project/mip/
 - https://github.com/coin-or/python-mip
-- Eclipse Public License 2.0 (considered **GPL**-incompatible https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses)
-- **requires Python 3.5 or newer**
+- Eclipse Public License 2.0 (considered **GPL-incompatible** https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses)

 **PICOS** - a user friendly Python API to several conic and integer programming solvers, very much like YALMIP or
 CVX under MATLAB.
mkoeppe commented 2 years ago

Description changed:

--- 
+++ 
@@ -1,6 +1,7 @@
 The purpose of this ticket is to 
 - connect SageMath to interfaces to optimization solvers that are maintained outside of the Sage project,
-- integrate the related developer and user communities.
+- integrate the related developer and user communities,
+- provide an entry point for [GSoC 2022 projects](https://wiki.sagemath.org/GSoC/2022)

 **Status quo in Sage:**
 - Frontend class [MixedIntegerLinearProgram](https://doc.sagemath.org/html/en/reference/numerical/sage/numerical/mip.html#sage.numerical.mip.MixedIntegerLinearProgram)
mkoeppe commented 2 years ago

Description changed:

--- 
+++ 
@@ -104,9 +104,10 @@
 - #33487: CyLP is a Python interface to COIN-OR’s Linear and mixed-integer program solvers (CLP, CBC, and CGL). CyLP’s unique feature is that you can use it to alter the solution process of the solvers from within Python. For example, you may define cut generators, branch-and-bound strategies, and primal/dual Simplex pivot rules completely in Python.
 - is it maintained?? https://github.com/coin-or/CyLP/issues

-**cbcpy** (new August 2019 according to ​https://pypi.org/project/cbcpy/) 
-- upstream devs for cbc have published their own python interface ​https://git.patrikdufresne.com/pdsl/cbcpy
+**[[cbcpy** (LGPL; new August 2019 according to ​https://pypi.org/project/cbcpy/; no activity since then) 
+- upstream devs for cbc have published their own python interface ​https://gitlab.com/ikus-soft/cbcpy
 - the fact that it uses swig may be an obstacle for immediate inclusion
+

 **Gurobi**, **CPLEX**
 - they come with their own standard Python APIs, which we could use instead of building our own cython interface
mkoeppe commented 2 years ago

Description changed:

--- 
+++ 
@@ -104,7 +104,7 @@
 - #33487: CyLP is a Python interface to COIN-OR’s Linear and mixed-integer program solvers (CLP, CBC, and CGL). CyLP’s unique feature is that you can use it to alter the solution process of the solvers from within Python. For example, you may define cut generators, branch-and-bound strategies, and primal/dual Simplex pivot rules completely in Python.
 - is it maintained?? https://github.com/coin-or/CyLP/issues

-**[[cbcpy** (LGPL; new August 2019 according to ​https://pypi.org/project/cbcpy/; no activity since then) 
+**cbcpy** (LGPL; new August 2019 according to ​https://pypi.org/project/cbcpy/; no activity since then) 
 - upstream devs for cbc have published their own python interface ​https://gitlab.com/ikus-soft/cbcpy
 - the fact that it uses swig may be an obstacle for immediate inclusion
mkoeppe commented 2 years ago

Description changed:

--- 
+++ 
@@ -49,6 +49,7 @@
 **cvxpy** - #31962
 - use CBC via **cylp**
 - experimental CBC interface via **python-mip** - https://github.com/cvxpy/cvxpy/issues/1265, https://pypi.org/project/mip-cvxpy/
+- https://github.com/cvxpy/cvxpy/issues/1704: Link to `MathOptInterface.jl`

 **or-tools** - #33493
mkoeppe commented 2 years ago

Description changed:

--- 
+++ 
@@ -19,7 +19,7 @@
     - https://github.com/sagemath/sage-numerical-backends-coin: COIN backend (CBC) - very basic, no support for setting solver parameters such as time limit
     - https://github.com/sagemath/sage-numerical-backends-cplex: CPLEX backend
     - https://github.com/sagemath/sage-numerical-backends-gurobi: Gurobi backend
-- Very small developer community
+- Optimization interface is maintained by a very small part of the Sage developer community

 **Tickets:**
mkoeppe commented 2 years ago

Description changed:

--- 
+++ 
@@ -49,6 +49,7 @@
 **cvxpy** - #31962
 - use CBC via **cylp**
 - experimental CBC interface via **python-mip** - https://github.com/cvxpy/cvxpy/issues/1265, https://pypi.org/project/mip-cvxpy/
+- https://github.com/cvxpy/cvxpy/issues/1649#issuecomment-1067148937: Link to OR-tools solver abstraction
 - https://github.com/cvxpy/cvxpy/issues/1704: Link to `MathOptInterface.jl`

 **or-tools** - #33493
mkoeppe commented 2 years ago

Description changed:

--- 
+++ 
@@ -53,6 +53,10 @@
 - https://github.com/cvxpy/cvxpy/issues/1704: Link to `MathOptInterface.jl`

 **or-tools** - #33493
+
+https://github.com/KarrLab/conv_opt
+- MIT license
+- Cbc, CVXOPT, FICO XPRESS, GLPK, Gurobi, IBM CPLEX, MINOS, Mosek, quadprog, SciPy, and SoPlex.

 **PuLP**
 - https://github.com/coin-or/pulp
mkoeppe commented 2 years ago
comment:73

Replying to @tkralphs:

I am sorry, I didn't intend to offend anyone

No worries, you did mark it as <rant>, but the end tag is missing

mkoeppe commented 2 years ago

Description changed:

--- 
+++ 
@@ -3,13 +3,16 @@
 - integrate the related developer and user communities,
 - provide an entry point for [GSoC 2022 projects](https://wiki.sagemath.org/GSoC/2022)

-**Status quo in Sage:**
+## [SageMath](../wiki/SageMath) status quo: Front end
 - Frontend class [MixedIntegerLinearProgram](https://doc.sagemath.org/html/en/reference/numerical/sage/numerical/mip.html#sage.numerical.mip.MixedIntegerLinearProgram)
     - mutable (can call `add_constraint`, `set_integer`, `new_variable` etc. and then re-solve)
     - solver-independent and solver-specific parameters (`solver_parameter`)
     - widely used in Sage library code for `sage.graphs`, `sage.coding`, `sage.combinat`, ...
     - [MIPVariable](https://doc.sagemath.org/html/en/reference/numerical/sage/numerical/mip.html#sage.numerical.mip.MIPVariable) - indexed by arbitrary objects
     - some connections to [Polyhedron](https://doc.sagemath.org/html/en/reference/discrete_geometry/index.html#polyhedral-computations) class and to [InteractiveLPProblem](https://doc.sagemath.org/html/en/reference/numerical/sage/numerical/interactive_simplex_method.html) (didactical code)
+
+## [SageMath](../wiki/SageMath) status quo: Back ends
+
 - [In-tree backends](https://github.com/sagemath/sage-prod/tree/develop/src/sage/numerical/backends), using Cython, with varying degrees of implementation quality
     - GLPK backend - complete, includes support for tableau data and GLPK's exact rational mode
     - InteractiveLP backend - basic, provide LP only for algebraic LPs
@@ -21,7 +24,7 @@
     - https://github.com/sagemath/sage-numerical-backends-gurobi: Gurobi backend
 - Optimization interface is maintained by a very small part of the Sage developer community

-**Tickets:**
+## [SageMath](../wiki/SageMath) tickets and tasks

 - #28175 Move sage optimization backends to separate Cython packages to remove `OptionalExtension` problems
 - Template for minimal Python-based backends (`interactivelp_backend.pyx` is implemented in Cython just because a Cython template was available)
@@ -38,15 +41,12 @@

 Related:
 - #20302 Meta-ticket: Improvements to `MixedIntegerLinearProgram`, its backends, and `InteractiveLinearProgram`
-.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  
-
-References:
-
-**Key Python software (solver-independent):**

+## Key Python software (solver-independent)

 **cvxpy** - #31962
+- permissive open source license: Apache 2.0
 - use CBC via **cylp**
 - experimental CBC interface via **python-mip** - https://github.com/cvxpy/cvxpy/issues/1265, https://pypi.org/project/mip-cvxpy/
 - https://github.com/cvxpy/cvxpy/issues/1649#issuecomment-1067148937: Link to OR-tools solver abstraction
@@ -54,12 +54,12 @@

 **or-tools** - #33493

-https://github.com/KarrLab/conv_opt
+**conv_opt** - https://github.com/KarrLab/conv_opt
 - MIT license
 - Cbc, CVXOPT, FICO XPRESS, GLPK, Gurobi, IBM CPLEX, MINOS, Mosek, quadprog, SciPy, and SoPlex.

-**PuLP**
-- https://github.com/coin-or/pulp
+**PuLP** - https://github.com/coin-or/pulp
+- permissive open source license (BSD?)
 - Installation with `sage -pip install pulp` works
 - Frontend: a basic modeling system 
    - example: https://github.com/coin-or/pulp/blob/master/examples/WhiskasModel1.py
@@ -72,6 +72,7 @@
   - **PuLP is currently looking for a co-maintainer** (https://github.com/coin-or/pulp/issues/183)

 **Pyomo**
+- permissive open source license: BSD
 - http://www.pyomo.org/ 
 - installation with `sage -pip install pyomo` works
 - some file-based, some API-based interfaces (direct/persistent) - see [solvers directory](https://github.com/Pyomo/pyomo/tree/master/pyomo/solvers/plugins/solvers)
@@ -96,13 +97,24 @@
 - https://gitlab.com/picos-api/picos
 - https://pypi.org/project/PICOS/

-**Key Python software (solver-dependent):**
+
+## C, C++ solver abstractions
+
+**or-tools** (#33493) `​linear_solver` wrapper
+- supporting CLP, CBC, GLPK, Gurobi, SCIP, XPRESS
+- permissive open source license: Apache 2.0
+
+**COIN-OR OSI**
+- **incompatible copyleft license**: Eclipse Public License 2.0
+
+
+## Key Python software (solver-dependent)

 **scipy.optimize**

 - #32282 Add LP solver backends for HiGHS via scipy.optimize.linprog

-**GLPK** 
+Interfaces to **GLPK**
 - it looks like ​https://github.com/biosustain/swiglpk/releases is the best maintained. Excluding sage and cvxopt.
 - see https://en.wikibooks.org/wiki/GLPK/Python for a list of other glpk bindings

@@ -125,16 +137,11 @@
 **PySCIPOpt**
 - #21003

-**Other relevant software**
+## Other relevant software

 - PaPILO: Parallel Presolve for Integer and Linear Optimization (https://github.com/scipopt/papilo/) - LGPL license, C++ library; used in SCIP

-.  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  .  
-
-**Possible integration routes via Julia**
+## Possible integration routes via Julia

 - `MathOptInterface` - https://arxiv.org/pdf/2002.03447.pdf

-
-
-
mkoeppe commented 2 years ago

Description changed:

--- 
+++ 
@@ -44,6 +44,12 @@

 ## Key Python software (solver-independent)
+
+Selection criteria for solver-independent interfaces:
+- Does it use a compatible, permissive, open source license?
+- Does it provide detailed access to the solver that allows for updating problems and warmstarting?
+- Is it under active development?
+

 **cvxpy** - #31962
 - permissive open source license: Apache 2.0
@@ -110,8 +116,10 @@

 ## Key Python software (solver-dependent)

-**scipy.optimize**
+The Python interfaces that target only one solver are usually careful in not having more restrictive licenses than the targeted solver.

+**scipy.optimize** (vendors HiGHS)
+- Permissive open source licenses: SciPy: BSD 3-clause; HiGHS: MIT license
 - #32282 Add LP solver backends for HiGHS via scipy.optimize.linprog

 Interfaces to **GLPK**
@@ -120,6 +128,7 @@

 **cylp**
 - #33487: CyLP is a Python interface to COIN-OR’s Linear and mixed-integer program solvers (CLP, CBC, and CGL). CyLP’s unique feature is that you can use it to alter the solution process of the solvers from within Python. For example, you may define cut generators, branch-and-bound strategies, and primal/dual Simplex pivot rules completely in Python.
+- same license as CBC/CLP/CGL
 - is it maintained?? https://github.com/coin-or/CyLP/issues

 **cbcpy** (LGPL; new August 2019 according to ​https://pypi.org/project/cbcpy/; no activity since then) 
@@ -136,6 +145,7 @@

 **PySCIPOpt**
 - #21003
+- PySCIPOpt: MIT license; SCIP: non-free "academic" license

 ## Other relevant software
mkoeppe commented 2 years ago

Description changed:

--- 
+++ 
@@ -57,6 +57,7 @@
 - experimental CBC interface via **python-mip** - https://github.com/cvxpy/cvxpy/issues/1265, https://pypi.org/project/mip-cvxpy/
 - https://github.com/cvxpy/cvxpy/issues/1649#issuecomment-1067148937: Link to OR-tools solver abstraction
 - https://github.com/cvxpy/cvxpy/issues/1704: Link to `MathOptInterface.jl`
+- under active development; maintainers appears to respond quickly to issues/PRs: [cvxpy/cvxpy#1705](https://github.com/cvxpy/cvxpy/pull/1705), [cvxpy/cvxpy#1707](https://github.com/cvxpy/cvxpy/pull/1707), [cvxpy/cvxpy#1719](https://github.com/cvxpy/cvxpy/pull/1719)

 **or-tools** - #33493
mkoeppe commented 2 years ago

Description changed:

--- 
+++ 
@@ -57,7 +57,7 @@
 - experimental CBC interface via **python-mip** - https://github.com/cvxpy/cvxpy/issues/1265, https://pypi.org/project/mip-cvxpy/
 - https://github.com/cvxpy/cvxpy/issues/1649#issuecomment-1067148937: Link to OR-tools solver abstraction
 - https://github.com/cvxpy/cvxpy/issues/1704: Link to `MathOptInterface.jl`
-- under active development; maintainers appears to respond quickly to issues/PRs: [cvxpy/cvxpy#1705](https://github.com/cvxpy/cvxpy/pull/1705), [cvxpy/cvxpy#1707](https://github.com/cvxpy/cvxpy/pull/1707), [cvxpy/cvxpy#1719](https://github.com/cvxpy/cvxpy/pull/1719)
+- under active development; maintainers appear to respond quickly to issues/PRs: [cvxpy/cvxpy#1705](https://github.com/cvxpy/cvxpy/pull/1705), [cvxpy/cvxpy#1707](https://github.com/cvxpy/cvxpy/pull/1707), [cvxpy/cvxpy#1719](https://github.com/cvxpy/cvxpy/pull/1719)

 **or-tools** - #33493
mkoeppe commented 2 years ago

Description changed:

--- 
+++ 
@@ -57,7 +57,7 @@
 - experimental CBC interface via **python-mip** - https://github.com/cvxpy/cvxpy/issues/1265, https://pypi.org/project/mip-cvxpy/
 - https://github.com/cvxpy/cvxpy/issues/1649#issuecomment-1067148937: Link to OR-tools solver abstraction
 - https://github.com/cvxpy/cvxpy/issues/1704: Link to `MathOptInterface.jl`
-- under active development; maintainers appear to respond quickly to issues/PRs: [cvxpy/cvxpy#1705](https://github.com/cvxpy/cvxpy/pull/1705), [cvxpy/cvxpy#1707](https://github.com/cvxpy/cvxpy/pull/1707), [cvxpy/cvxpy#1719](https://github.com/cvxpy/cvxpy/pull/1719)
+- as of 2022 under active development; maintainers appear to respond quickly to issues/PRs: [cvxpy/cvxpy#1705](https://github.com/cvxpy/cvxpy/pull/1705), [cvxpy/cvxpy#1707](https://github.com/cvxpy/cvxpy/pull/1707), [cvxpy/cvxpy#1719](https://github.com/cvxpy/cvxpy/pull/1719)

 **or-tools** - #33493
mkoeppe commented 2 years ago

Description changed:

--- 
+++ 
@@ -130,7 +130,7 @@
 **cylp**
 - #33487: CyLP is a Python interface to COIN-OR’s Linear and mixed-integer program solvers (CLP, CBC, and CGL). CyLP’s unique feature is that you can use it to alter the solution process of the solvers from within Python. For example, you may define cut generators, branch-and-bound strategies, and primal/dual Simplex pivot rules completely in Python.
 - same license as CBC/CLP/CGL
-- is it maintained?? https://github.com/coin-or/CyLP/issues
+- as of Mar 2022: [many open issues](https://github.com/coin-or/CyLP/issues), minimal maintenance mode by 1 maintainer who is cooperative on receiving PRs: [coin-or/CyLP#153](https://github.com/coin-or/CyLP/pull/153), [coin-or/CyLP#155](https://github.com/coin-or/CyLP/pull/155), [coin-or/CyLP#156](https://github.com/coin-or/CyLP/pull/156), [coin-or/CyLP#157](https://github.com/coin-or/CyLP/pull/157)

 **cbcpy** (LGPL; new August 2019 according to ​https://pypi.org/project/cbcpy/; no activity since then) 
 - upstream devs for cbc have published their own python interface ​https://gitlab.com/ikus-soft/cbcpy
mkoeppe commented 2 years ago

Description changed:

--- 
+++ 
@@ -110,6 +110,7 @@
 **or-tools** (#33493) `​linear_solver` wrapper
 - supporting CLP, CBC, GLPK, Gurobi, SCIP, XPRESS
 - permissive open source license: Apache 2.0
+- quick with "wontfix" - [google/or-tools#3205](https://github.com/google/or-tools/issues/3205)

 **COIN-OR OSI**
 - **incompatible copyleft license**: Eclipse Public License 2.0
mkoeppe commented 2 years ago

Description changed:

--- 
+++ 
@@ -124,6 +124,9 @@
 - Permissive open source licenses: SciPy: BSD 3-clause; HiGHS: MIT license
 - #32282 Add LP solver backends for HiGHS via scipy.optimize.linprog

+**highspy** (pybind11-based interface to HiGHS)
+- #33919 Add MILP solver backends for HiGHS via highspy
+
 Interfaces to **GLPK**
 - it looks like ​https://github.com/biosustain/swiglpk/releases is the best maintained. Excluding sage and cvxopt.
 - see https://en.wikibooks.org/wiki/GLPK/Python for a list of other glpk bindings
mkoeppe commented 2 years ago

Description changed:

--- 
+++ 
@@ -51,7 +51,7 @@
 - Is it under active development?

-**cvxpy** - #31962
+**cvxpy** - Meta-ticket #33920
 - permissive open source license: Apache 2.0
 - use CBC via **cylp**
 - experimental CBC interface via **python-mip** - https://github.com/cvxpy/cvxpy/issues/1265, https://pypi.org/project/mip-cvxpy/
mkoeppe commented 1 year ago

Description changed:

--- 
+++ 
@@ -60,6 +60,8 @@
 - as of 2022 under active development; maintainers appear to respond quickly to issues/PRs: [cvxpy/cvxpy#1705](https://github.com/cvxpy/cvxpy/pull/1705), [cvxpy/cvxpy#1707](https://github.com/cvxpy/cvxpy/pull/1707), [cvxpy/cvxpy#1719](https://github.com/cvxpy/cvxpy/pull/1719)

 **or-tools** - #33493
+- Upcoming ("soon" as of 2022-08) new MathOpt DSL (Python)
+

 **conv_opt** - https://github.com/KarrLab/conv_opt
 - MIT license
mkoeppe commented 1 year ago

Description changed:

--- 
+++ 
@@ -152,11 +152,11 @@

 **PySCIPOpt**
 - #21003
-- PySCIPOpt: MIT license; SCIP: non-free "academic" license
+- PySCIPOpt: MIT license; SCIP: Apache 2.0

 ## Other relevant software

-- PaPILO: Parallel Presolve for Integer and Linear Optimization (https://github.com/scipopt/papilo/) - LGPL license, C++ library; used in SCIP
+- #34726 PaPILO: Parallel Presolve for Integer and Linear Optimization (https://github.com/scipopt/papilo/) - LGPL license, C++ library; used in SCIP

 ## Possible integration routes via Julia
mkoeppe commented 1 year ago

Description changed:

--- 
+++ 
@@ -150,13 +150,14 @@
 **python-qsoptex**
 - https://github.com/jonls/python-qsoptex (see #18766)

-**PySCIPOpt**
-- #21003
-- PySCIPOpt: MIT license; SCIP: Apache 2.0
+**SCIP, PySCIPOpt** (now open source)
+- #34726 Optional package `papilo`: Parallel Presolve for Integer and Linear Optimization (https://github.com/scipopt/papilo/) - LGPL license
+- #34742 Optional package `soplex` (dependency of scip)
+- #31329 Update `scipoptsuite` to 8.0.2 (now open source!)
+- #21003 Add package `pyscipopt` (MIT license), add MIP backend
+- #34749 Package `scipsdp`
+- #34750 Packages `gcg`, `PyGCGOpt`

-## Other relevant software
-
-- #34726 PaPILO: Parallel Presolve for Integer and Linear Optimization (https://github.com/scipopt/papilo/) - LGPL license, C++ library; used in SCIP

 ## Possible integration routes via Julia
crsdvaibhav commented 1 year ago

@mkoeppe Hey, I am Vaibhav from IIT BHU. I was looking forward to working on this issue for GSoC. I contacted you earlier via the sage-gsoc group, where you pointed out literature by Vanderbei, which I have been studying. Can you point out which issue would be good to start working on here? Thanks!

mkoeppe commented 1 year ago

35198 could be a good starting point

ashutosh887 commented 1 year ago

I'm willing to contribute to this Project @mkoeppe Sir Please guide me to some issues to start with I'm really willing to contribute

mkoeppe commented 1 year ago

Try #31962

ashutosh887 commented 1 year ago

Sure Thanks @mkoeppe Sir

latifbhatti commented 1 year ago

I want to contribute on this project. I have knowledge about manifold. Guide me more about good issue to start.

jnash10 commented 1 year ago

Hi @mkoeppe ,

I'd like to work on this section for GSoC/23.

If it is okay, as my proof of concept on being able to contribute to this Meta-ticket, I'll be taking one of this issues: #15356 or #7300 as referenced in meta-ticket #20302.

I have moderate experience in optimization (eg. Simplex Method, Integer optimization, etc) and its applied side via OR-Tools as I'm currently crediting an applied optimization course in my Data Science and Engineering degree at the Indian Institute of Science Education and Research Bhopal. 6+ years in Python.

I currently have one PR with a positive review in SageMath: #35113

mkoeppe commented 1 year ago

I'll be taking one of this issues: #15356 or #7300

These are pretty old issues and possibly not very clear.

35308 could be a good way to start

jnash10 commented 1 year ago

I'll be taking one of this issues: #15356 or #7300

These are pretty old issues and possibly not very clear. #35308 could be a good way to start

Alright!

Thank you, on it!

Carlxuzhl commented 1 year ago

Hi @mkoeppe, I'm Zhongling Xu from UT-Austin ORIE program. I have experience in optimization (convex optimization, linear programming and integer programming) and Python development. I would like to contribute to the idea "Enhanced optimization solver interfaces for Sage", which aligns my knowledge and skill set. Could you guide me to some good issues to start with? Thanks!

mkoeppe commented 1 year ago

Hi @Carlxuzhl, thanks for your interest! To get started with the MixedIntegerLinearProgram class in Sage, it could be interesting to first explore the frontend form the user's point of view. Just as a suggestion, we may want to add some exposition of integer programming methods for geometric packing/covering problems to Sage, for example 2d bin packing. A nontechnical task, just to get started with our workflow & infrastructure, could be to improve the documentation of https://doc.sagemath.org/html/en/reference/combinat/sage/combinat/tiling.html by adding plots (using the Sphinx .. PLOT:: directive).

Carlxuzhl commented 1 year ago

Hi @Carlxuzhl, thanks for your interest! To get started with the MixedIntegerLinearProgram class in Sage, it could be interesting to first explore the frontend form the user's point of view. Just as a suggestion, we may want to add some exposition of integer programming methods for geometric packing/covering problems to Sage, for example 2d bin packing. A nontechnical task, just to get started with our workflow & infrastructure, could be to improve the documentation of https://doc.sagemath.org/html/en/reference/combinat/sage/combinat/tiling.html by adding plots (using the Sphinx .. PLOT:: directive).

Thank you for the guidance! I will work on improving the documentation to get started.

jnash10 commented 1 year ago

I'll be taking one of this issues: #15356 or #7300

These are pretty old issues and possibly not very clear. #35308 could be a good way to start

Since #35329 (still awaiting approval) has made good progress to solve it, can you suggest some other issue?

Thanks!

mkoeppe commented 1 year ago

@jnash10 Try #31962

yangtx7 commented 3 months ago

Hi @mkoeppe, I'd like to work on "Enhanced optimization solver interfaces for Sage" section for GSoC'24. I found this project aligns with my interest and technical skills because I am an incoming CS PhD student and my research focus on ML-based MILP solver and ML-based MILP instance generator. I am familiar with Python interface of SCIP, Gurobi and CPLEX. Could you please guide me on specific issues or tasks that I can start working on?