#28175 closed enhancement (fixed)
Move optional sage optimization backends (COIN, CPLEX, Gurobi) to separate Cython packages to remove OptionalExtension problems
Reported by:  mkoeppe  Owned by:  

Priority:  major  Milestone:  sage9.1 
Component:  numerical  Keywords:  
Cc:  isuruf, saraedum, fbissey, dimpase, tmonteil, vdelecroix, slabbe  Merged in:  
Authors:  Matthias Koeppe  Reviewers:  Dima Pasechnik 
Report Upstream:  N/A  Work issues:  
Branch:  1279897 (Commits, GitHub, GitLab)  Commit:  
Dependencies:  Stopgaps: 
Description (last modified by )
sage.numerical.backends
depends on very little from Sage. We propose to split out the optional backends (COIN, CPLEX, Gurobi) to separate Cython packages.
With this ticket, sagelib no longer has the optional dependency on cbc. Instead, these new packages depend on the sage
package (i.e., sagelib).
This makes it easier to reconfigure when new solvers are installed, as sagelib does not have to be recompiled. By eliminating the use of the optional extensions mechanisms from sagelib, this will also simplify packaging binary distributions.
The new packages are on PyPI:
wget P upstream https://files.pythonhosted.org/packages/29/8a/65fd90a890fcfb56166c4071aa7a4fb5b865d313304f60474870f0e89998/sage_numerical_backends_cplex9.0b12.tar.gz wget P upstream https://files.pythonhosted.org/packages/2c/5c/e1532bb6cde28cf86ebffd408ccb500d7b846bc29bbd1c5e479a2f18acb6/sage_numerical_backends_gurobi9.0b12.tar.gz wget P upstream https://files.pythonhosted.org/packages/17/f4/308d3e151d82daf2c58ca26bce157fac31f763b2b60b5173243c09291e0a/sage_numerical_backends_coin9.0b12.tar.gz
Development here:
 https://github.com/mkoeppe/sagenumericalbackendscplex
 https://github.com/mkoeppe/sagenumericalbackendscoin
 https://github.com/mkoeppe/sagenumericalbackendsgurobi
See also:
 Followup: #28920: Move sage optimization backend framework (
sage.numerical.backends
) to separate Cython packages  #26511  Metaticket: Use Python optimization interfaces: PuLP, Pyomo, cylp...
 https://groups.google.com/forum/#!topic/sagepackaging/_FLDkqD2X8c
Change History (69)
comment:1 followup: ↓ 2 Changed 2 years ago by
comment:2 in reply to: ↑ 1 Changed 2 years ago by
Replying to dcoudert:
These backends are used in graphs. So what will happen if linear programming backends are in a separate package ?
In my plan, the backends would be a standard package of the sage distribution, and the cython modules it provides would be automatically imported when MixedIntegerLinearProgram? is used.
comment:3 Changed 22 months ago by
 Description modified (diff)
 Milestone changed from sagewishlist to sage9.0
 Summary changed from Move sage optimization backends to a separate package to Move sage optimization backends to separate Cython packages to remove OptionalExtension problems
comment:4 Changed 22 months ago by
 Cc isuruf saraedum fbissey added
comment:5 Changed 22 months ago by
For glpk it looks like https://github.com/biosustain/swiglpk/releases is the best maintained. Excluding sage and cvxopt.
comment:6 Changed 22 months ago by
 Description modified (diff)
comment:7 Changed 22 months ago by
 Description modified (diff)
comment:8 Changed 21 months ago by
 Cc dimpase added
 Description modified (diff)
 Summary changed from Move sage optimization backends to separate Cython packages to remove OptionalExtension problems to Move optional sage optimization backends to separate Cython packages to remove OptionalExtension problems
I have prepared a first module, https://github.com/mkoeppe/sagenumericalbackendscoin.
It depends on Sage (as it inherits from sage.numerical.backends.generic_backend.GenericBackend
).
comment:9 Changed 21 months ago by
 Description modified (diff)
 Summary changed from Move optional sage optimization backends to separate Cython packages to remove OptionalExtension problems to Move optional sage optimization backends (COIN, CPLEX, Gurobi) to separate Cython packages to remove OptionalExtension problems
comment:10 Changed 21 months ago by
Is there a git branch to try, replacing Sage's current COINOR backend with this one?
comment:11 Changed 21 months ago by
Not yet (working on it right now), but the 3 backends already pass their test suites separately.
comment:12 Changed 21 months ago by
 Branch set to u/mkoeppe/move_optional_sage_optimization_backends_to_separate_cython_packages_to_remove_optionalextension_problems
comment:13 Changed 21 months ago by
 Commit set to 437fec50bb78832cd797f263f73732c6993c5719
Branch pushed to git repo; I updated commit sha1. New commits:
437fec5  Fixup dependencies

comment:14 Changed 21 months ago by
Now the packages can be installed using sage i c
... please test
comment:15 Changed 21 months ago by
remains of copypaste, I see PyNormaliz
in the branch...
comment:16 Changed 21 months ago by
 Commit changed from 437fec50bb78832cd797f263f73732c6993c5719 to 846ca9a1520562f5c375db8c2ddf45ef5133956c
Branch pushed to git repo; I updated commit sha1. New commits:
846ca9a  Replace CoinBackend, CPLEXBackend, GurobiBackend by their versions imported from sage_numerical_backends_*

comment:17 Changed 21 months ago by
 Status changed from new to needs_review
comment:18 Changed 21 months ago by
 Commit changed from 846ca9a1520562f5c375db8c2ddf45ef5133956c to 3c557b48cf069ebfb61fe757894808403ba74b1c
Branch pushed to git repo; I updated commit sha1. New commits:
3c557b4  build/pkgs/sage_numerical_backends_*/spkginstall: Adjust error message

comment:19 Changed 21 months ago by
 Commit changed from 3c557b48cf069ebfb61fe757894808403ba74b1c to 84c83f26b23fe2714b9078e63e85bc45525cb896
Branch pushed to git repo; I updated commit sha1. New commits:
84c83f2  src/doc/en/thematic_tutorials/linear_programming.rst: Update COIN/CPLEX/Gurobi install instructions

comment:20 Changed 21 months ago by
 Commit changed from 84c83f26b23fe2714b9078e63e85bc45525cb896 to 48287667e7c3178c6da2cf4e6171d353e2af60d7
Branch pushed to git repo; I updated commit sha1. New commits:
4828766  MixedIntegerLinearProgram: Update docstrings for class and __init__, refer to thematic tutorial, and reduce copypaste

comment:21 Changed 21 months ago by
 Commit changed from 48287667e7c3178c6da2cf4e6171d353e2af60d7 to 189d60bc565f05a3c72c76da8b2cabc863e08a4f
Branch pushed to git repo; I updated commit sha1. New commits:
189d60b  get_solver: Reduce copypaste in docstring

comment:22 Changed 21 months ago by
 Cc tmonteil vdelecroix added
comment:23 Changed 21 months ago by
 Description modified (diff)
comment:24 Changed 21 months ago by
 Commit changed from 189d60bc565f05a3c72c76da8b2cabc863e08a4f to 53f377414b94308b6ad3bfc41fdf4ff7545e0df5
comment:25 Changed 21 months ago by
Since these are currently part of the Sage distribution, it makes sense to me to have them as standard packages (in regards to comment:2). Similarly I would argue they do not require a vote on sagedevel, but I would just post something quick there to see if there are any objections.
comment:26 Changed 21 months ago by
They can't be standard packages because they only compile if the respective solvers are installed.
comment:27 Changed 21 months ago by
Note that I narrowed down the ticket recently; the early comments were on a broader proposal to move ALL backends out to separate packages.
comment:28 Changed 21 months ago by
Ah, I see. Sorry for the noise.
comment:29 Changed 21 months ago by
coin
is problematic for me on sageongentoo, and has been for a while. So, making it a standard package would be annoying. The coin
interface doesn't seem to be very stable and coin
in sage is not updated often (neither it is in gentoo). Version mismatch usually lead to a failure to build the interface.
comment:30 followup: ↓ 32 Changed 21 months ago by
Well, the point of this ticket is to make the sage build *less* dependent on coin, not more.
Also, I'd appreciate any help with testing https://github.com/mkoeppe/sagenumericalbackendscoin on sage installations such as the one provided on gentoo. My current test scripts (using GitHub actions) cover condaforge so far, and I'm working on various debian/ubuntu flavors.
comment:31 Changed 21 months ago by
 Description modified (diff)
comment:32 in reply to: ↑ 30 Changed 21 months ago by
Replying to mkoeppe:
Well, the point of this ticket is to make the sage build *less* dependent on coin, not more.
Also, I'd appreciate any help with testing https://github.com/mkoeppe/sagenumericalbackendscoin on sage installations such as the one provided on gentoo. My current test scripts (using GitHub actions) cover condaforge so far, and I'm working on various debian/ubuntu flavors.
I will have a look at it. It looks interesting but where does it install itself? I cannot promise speedy review as I about to have my annual internet /computer detox for a few days :)
comment:33 Changed 21 months ago by
It just installs itself as a Python package named sage_numerical_backends_coin.coin_backend
(note, underscores, not dots).
The https://github.com/mkoeppe/sagenumericalbackendscoin/blob/master/README.md explains how to use it, including how to patch it into a sage for testing purposes.
comment:34 followup: ↓ 38 Changed 21 months ago by
for coin, there is a verssion mismatch. On pypi and in the ticket description the minor version is b9, in build/pkgs/ it is b10, the latest on github is b12 :)
So I took b12 from github, renamed the tarfile (arrgh), bumped up the version,

build/pkgs/sage_numerical_backends_coin/checksums.ini
diff git a/build/pkgs/sage_numerical_backends_coin/checksums.ini b/build/pkgs/sage_numerical_backends_coin/checksums.ini index 03b250b653..3062652fc1 100644
a b 1 1 tarball=sage_numerical_backends_coinVERSION.tar.gz 2 sha1= fd96cfc224f1f45bad6bacaaf37df3904fa7a5613 md5= 98e5a002648cdf3167df2dafb16cde474 cksum= 8694390562 sha1=0c424f8d01bdd44169630bc898738a4ee146ea2c 3 md5=09b6b74d7c8b9b3526424cf8850f8700 4 cksum=1339126990 
build/pkgs/sage_numerical_backends_coin/packageversion.txt
diff git a/build/pkgs/sage_numerical_backends_coin/packageversion.txt b/build/pkgs/sage_numerical_backends_coin/packageversion.txt index 5d6a14cdd9..1700f7be00 100644
a b 1 9.0b1 01 9.0b12
and then
$ SAGE_CHECK=yes ./sage i sage_numerical_backends_coin
worked on Debian with system's cbc 2.9.9. (using #28908)
comment:35 followup: ↓ 39 Changed 21 months ago by
Where are the tests from now gone sage/numerical/backends/coin_backend.pyx
?
Are they all being run while installing with SAGE_CHECK=yes
?
comment:36 followup: ↓ 43 Changed 21 months ago by
In a way related to #26511, upstream devs for cbc have published their own python interface https://git.patrikdufresne.com/pdsl/cbcpy the fact that it uses swig may be an obstacle for immediate inclusion but switching to something maintained externally is something to think about. The project is quite new (August 2019 according to https://pypi.org/project/cbcpy/ ) which is why it may escaped attention before.
comment:37 Changed 21 months ago by
in the environment as above for coin,
SAGE_CHECK=yes ./sage f sage_numerical_backends_gurobi
fails with
... [sage_numerical_backends_gurobi9.0b9] Running the test suite for sage_numerical_backends_gurobi9.0b9... [sage_numerical_backends_gurobi9.0b9] running test [sage_numerical_backends_gurobi9.0b9] Searching for sagepackage [sage_numerical_backends_gurobi9.0b9] Reading https://pypi.org/simple/sagepackage/ [sage_numerical_backends_gurobi9.0b9] Using gurobi_include_directories=['/home/dimpase/sage/upstream/gurobi900/linux64/include'], libraries=['gurobi90'], library_dirs=['/home/dimpase/sage/upstream/gurobi900/linux64/lib'] [sage_numerical_backends_gurobi9.0b9] Download error on https://pypi.org/simple/sagepackage/: [Errno 110] Connection timed out  Some packages may not be found! [sage_numerical_backends_gurobi9.0b9] Couldn't find index page for 'sagepackage' (maybe misspelled?) [sage_numerical_backends_gurobi9.0b9] Scanning index of all packages (this may take a while) [sage_numerical_backends_gurobi9.0b9] Reading https://pypi.org/simple/ [sage_numerical_backends_gurobi9.0b9] Download error on https://pypi.org/simple/: [Errno 110] Connection timed out  Some packages may not be found! [sage_numerical_backends_gurobi9.0b9] No local packages or working download links found for sagepackage [sage_numerical_backends_gurobi9.0b9] error: Could not find suitable distribution for Requirement.parse('sagepackage') [sage_numerical_backends_gurobi9.0b9] [sage_numerical_backends_gurobi9.0b9] real 1m4.289s [sage_numerical_backends_gurobi9.0b9] user 0m0.833s [sage_numerical_backends_gurobi9.0b9] sys 0m0.148s [sage_numerical_backends_gurobi9.0b9] ************************************************************************ [sage_numerical_backends_gurobi9.0b9] Error testing package sage_numerical_backends_gurobi9.0b9
comment:38 in reply to: ↑ 34 ; followup: ↓ 40 Changed 21 months ago by
Replying to dimpase:
So I took b12 from github, renamed the tarfile (arrgh)...
I recommend to take the release files from pypi  they have been built with setup.py sdist
.
comment:39 in reply to: ↑ 35 Changed 21 months ago by
Replying to dimpase:
Where are the tests from now gone
sage/numerical/backends/coin_backend.pyx
? Are they all being run while installing withSAGE_CHECK=yes
?
They are here:
https://github.com/mkoeppe/sagenumericalbackendscoin/blob/master/sage_numerical_backends_coin/coin_backend.pyx
They are run in the CI scripts of the package, and also when installing the spkg with SAGE_CHECK=yes
.
comment:40 in reply to: ↑ 38 Changed 21 months ago by
Replying to mkoeppe:
Replying to dimpase:
So I took b12 from github, renamed the tarfile (arrgh)...
I recommend to take the release files from pypi  they have been built with
setup.py sdist
.
sure, but b12 was not there yet. https://pypi.org/project/sagenumericalbackendscoin/#files says it made it there ~10 hours ago.
comment:41 followup: ↓ 42 Changed 21 months ago by
 Description modified (diff)
Created followup ticket, cleaned up ticket description
comment:42 in reply to: ↑ 41 ; followup: ↓ 44 Changed 21 months ago by
Replying to mkoeppe:
Created followup ticket, cleaned up ticket description
some links to packages are not up to date.
comment:43 in reply to: ↑ 36 Changed 21 months ago by
Replying to fbissey:
In a way related to #26511, upstream devs for cbc have published their own python interface https://git.patrikdufresne.com/pdsl/cbcpy the fact that it uses swig may be an obstacle for immediate inclusion but switching to something maintained externally is something to think about. The project is quite new (August 2019 according to https://pypi.org/project/cbcpy/ ) which is why it may escaped attention before.
Thank you! I've added this information to #26511.
comment:44 in reply to: ↑ 42 Changed 21 months ago by
comment:45 followup: ↓ 46 Changed 21 months ago by
Perhaps Gurobi (and similarly, CPLEX) can get some spkgconfigure.m4 helpers to reduce the hassle of
export GUROBI_HOME="/opt/gurobi900/linux64" export PATH="${PATH}:${GUROBI_HOME}/bin" export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${GUROBI_HOME}/lib"
to a minimum.
E.g. there could be an withgurobihome=
option which would default to
$GUROBI_HOME
,
and GUROBI_HOME
should be written in sageenvconfig
etc.
This is for a followup ticket, of course.
comment:46 in reply to: ↑ 45 ; followup: ↓ 47 Changed 21 months ago by
Replying to dimpase:
Perhaps Gurobi (and similarly, CPLEX) can get some spkgconfigure.m4 helpers to reduce the hassle of
export GUROBI_HOME="/opt/gurobi900/linux64" export PATH="${PATH}:${GUROBI_HOME}/bin" export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${GUROBI_HOME}/lib"to a minimum. E.g. there could be an
withgurobihome=
option which would default to$GUROBI_HOME
, andGUROBI_HOME
should be written insageenvconfig
etc.This is for a followup ticket, of course.
The macOS installer of Gurobi adds the following symlinks:
lrwxrxrx 1 root wheel 40 Apr 28 2016 /usr/local/bin/gurobi.env > //Library/gurobi651/mac64/bin/gurobi.env lrwxrxrx 1 root admin 39 Dec 24 12:11 /usr/local/bin/gurobi.sh > //Library/gurobi900/mac64/bin/gurobi.sh lrwxrxrx 1 root admin 39 Dec 24 12:11 /usr/local/bin/gurobi_cl > //Library/gurobi900/mac64/bin/gurobi_cl
See https://github.com/mkoeppe/sagenumericalbackendsgurobi/blob/master/README.md (just updated)  I am using gurobi.sh to do all the build configuration. Does this work on Linux?
comment:47 in reply to: ↑ 46 Changed 21 months ago by
Replying to mkoeppe:
Replying to dimpase:
Perhaps Gurobi (and similarly, CPLEX) can get some spkgconfigure.m4 helpers to reduce the hassle of
export GUROBI_HOME="/opt/gurobi900/linux64" export PATH="${PATH}:${GUROBI_HOME}/bin" export LD_LIBRARY_PATH="${LD_LIBRARY_PATH}:${GUROBI_HOME}/lib"to a minimum. E.g. there could be an
withgurobihome=
option which would default to$GUROBI_HOME
, andGUROBI_HOME
should be written insageenvconfig
etc.This is for a followup ticket, of course.
The macOS installer of Gurobi adds the following symlinks:
lrwxrxrx 1 root wheel 40 Apr 28 2016 /usr/local/bin/gurobi.env > //Library/gurobi651/mac64/bin/gurobi.env lrwxrxrx 1 root admin 39 Dec 24 12:11 /usr/local/bin/gurobi.sh > //Library/gurobi900/mac64/bin/gurobi.sh lrwxrxrx 1 root admin 39 Dec 24 12:11 /usr/local/bin/gurobi_cl > //Library/gurobi900/mac64/bin/gurobi_clSee https://github.com/mkoeppe/sagenumericalbackendsgurobi/blob/master/README.md (just updated)  I am using gurobi.sh to do all the build configuration. Does this work on Linux?
I see, on Linux it's not an installer but just a tgz.
comment:48 followup: ↓ 52 Changed 21 months ago by
Even on a Mac, with a multiuser installation one might want to hardcode GUROBI_HOME
and the license file location (GRB_LICENSE_FILE
).
comment:49 Changed 21 months ago by
 Description modified (diff)
comment:50 Changed 21 months ago by
 Commit changed from 53f377414b94308b6ad3bfc41fdf4ff7545e0df5 to 7caa365e427860e2b91387e014ef8d2ed06e16aa
Branch pushed to git repo; I updated commit sha1. New commits:
7caa365  Update sage_numerical_backends_gurobi and sage_numerical_backends_coin to 9.0b12

comment:51 Changed 21 months ago by
There's a new version of the gurobi package now. I have done some testing on Linux now, but I could not do a full test with a Gurobi license because it does not like to generate license keys on a Docker container. I have revised thee installation instructions to include Linux: https://github.com/mkoeppe/sagenumericalbackendsgurobi/blob/master/README.md
comment:52 in reply to: ↑ 48 Changed 21 months ago by
Replying to dimpase:
Even on a Mac, with a multiuser installation one might want to hardcode
GUROBI_HOME
and the license file location (GRB_LICENSE_FILE
).
Sure. The package looks at GUROBI_HOME
first.
comment:53 Changed 21 months ago by
 Description modified (diff)
comment:54 Changed 21 months ago by
 Commit changed from 7caa365e427860e2b91387e014ef8d2ed06e16aa to 2110ed3270741ec5f7211068ebbb91a787f4d815
Branch pushed to git repo; I updated commit sha1. New commits:
2110ed3  Update sage_numerical_backends_cplex to 9.0b12

comment:55 Changed 21 months ago by
Just updated the cplex backend. Ready for review.
comment:56 followup: ↓ 57 Changed 21 months ago by
I suggest using a namespace package for this. See https://packaging.python.org/guides/packagingnamespacepackages/
diff git a/setup.py b/setup.py index 176e75e..6dcffe2 100755  a/setup.py +++ b/setup.py @@ 44,8 +44,8 @@ cbc_library_dirs = cbc_pc['library_dirs'] cbc_include_dirs = cbc_pc['include_dirs'] ext_modules = [Extension('sage_numerical_backends_coin.coin_backend',  sources=[os.path.join('sage_numerical_backends_coin', +ext_modules = [Extension('sage.numerical.backends.coin_backend', + sources=[os.path.join('sage/numerical/backends', 'coin_backend.pyx')], libraries=cbc_libs, include_dirs=sage_include_directories() + cbc_include_dirs, @@ 81,7 +81,7 @@ except CompileError: print("Using compile_time_env: {}".format(compile_time_env), file=sys.stderr) setup(  name="sage_numerical_backends_coin", + name="sage.numerical.backends.coin_backend", version=readfile("VERSION").strip(), description="COINOR backend for Sage MixedIntegerLinearProgram", long_description = readfile("README.md"), # get the long description from the README @@ 109,9 +109,8 @@ setup( compile_time_env=compile_time_env), cmdclass = {'test': SageTest}, # adding a special setup command for tests keywords=['milp', 'linearprogramming', 'optimization'],  packages=['sage_numerical_backends_coin'],  package_dir={'sage_numerical_backends_coin': 'sage_numerical_backends_coin'},  package_data={'sage_numerical_backends_coin': ['*.pxd']}, + packages=['sage.numerical.backends'], + package_data={'sage.numerical.backends': ['*.pxd']}, install_requires = [# 'sage>=8', ### On too many distributions, sage is actually not known as a pip package 'sphinx'], setup_requires = ['pkgconfig'],
comment:57 in reply to: ↑ 56 Changed 21 months ago by
Replying to isuruf:
I suggest using a namespace package for this. See https://packaging.python.org/guides/packagingnamespacepackages/
Thanks a lot! I was briefly looking into this before I created the new packages, but was discouraged by various warnings on this page that seemed to imply one needs control of all packages sharing a namespace simultaneously. But I want the packages to work also with versions of sagelib that are already released. Which of the three approaches mentioned on the page do you specifically recommend?
comment:58 followups: ↓ 59 ↓ 60 Changed 21 months ago by
The diff above is for "1. native namespace package".
But I want the packages to work also with versions of sagelib that are already released.
This should work in the case of sagelib already released and if the optional extension is already installed, it will be overriden I think.
comment:59 in reply to: ↑ 58 Changed 21 months ago by
Replying to isuruf:
The diff above is for "1. native namespace package".
Thanks. This seems to be for Python 3 only, which would conflict with the goal of my packages to support older released versions such as sage 8.1 on Ubuntu bionic. But I'll keep it in mind for the future.
comment:60 in reply to: ↑ 58 ; followup: ↓ 62 Changed 21 months ago by
Thanks for the pull request at https://github.com/mkoeppe/sagenumericalbackendscoin/pull/4 . Let's continue the discussion regarding namespace packages there.
comment:61 Changed 21 months ago by
 Commit changed from 2110ed3270741ec5f7211068ebbb91a787f4d815 to 127989764d490e3d9359712970923bd993b14067
Branch pushed to git repo; I updated commit sha1. New commits:
1279897  build/pkgs/sage_numerical_backends_*/dependencies: Add some .pxd and .h as dependencies

comment:62 in reply to: ↑ 60 Changed 21 months ago by
Replying to mkoeppe:
Thanks for the pull request at https://github.com/mkoeppe/sagenumericalbackendscoin/pull/4 . Let's continue the discussion regarding namespace packages there.
I consider the idea of using namespace packages beyond the scope of the present ticket. I have created ticket #28925 (Modify clean_stale_files
to support modularization of sagelib
by namespace packages) for this direction.
comment:63 Changed 21 months ago by
 Cc slabbe added
comment:64 Changed 21 months ago by
 Milestone changed from sage9.0 to sage9.1
 Reviewers set to Dima Pasechnik
OK, coin and gurobi work, I can't test cplex, but I think it should be OK. It won't make it into 9.0, so I bumped up the milestone.
comment:65 Changed 21 months ago by
 Status changed from needs_review to positive_review
comment:66 Changed 21 months ago by
Thank you!
comment:67 Changed 21 months ago by
 Branch changed from u/mkoeppe/move_optional_sage_optimization_backends_to_separate_cython_packages_to_remove_optionalextension_problems to 127989764d490e3d9359712970923bd993b14067
 Resolution set to fixed
 Status changed from positive_review to closed
comment:68 followup: ↓ 69 Changed 21 months ago by
 Commit 127989764d490e3d9359712970923bd993b14067 deleted
Sorry, I was late testing this. It works for me with Ubuntu 16.04 running Gurobi 8.1.1 and CPLEX 12.9.
Question: how can I make sure that the tests involing Gurobi and cplex backends continue to work in the next dev versions of SageMath now that those files are gone from the sage library?
comment:69 in reply to: ↑ 68 Changed 21 months ago by
Replying to slabbe:
It works for me with Ubuntu 16.04 running Gurobi 8.1.1 and CPLEX 12.9.
Thanks for testing!
Question: how can I make sure that the tests involing Gurobi and cplex backends continue to work in the next dev versions of SageMath now that those files are gone from the sage library?
The tests are run when you install the new packages with sage i c
.
Can you be more precise on your plans.
These backends are used in graphs. So what will happen if linear programming backends are in a separate package ?