Opened 16 months ago

Closed 10 months ago

Last modified 10 months ago

#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: sage-9.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) Commit:
Dependencies: Stopgaps:

Description (last modified by mkoeppe)

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_cplex-9.0b12.tar.gz
wget -P upstream https://files.pythonhosted.org/packages/2c/5c/e1532bb6cde28cf86ebffd408ccb500d7b846bc29bbd1c5e479a2f18acb6/sage_numerical_backends_gurobi-9.0b12.tar.gz
wget -P upstream https://files.pythonhosted.org/packages/17/f4/308d3e151d82daf2c58ca26bce157fac31f763b2b60b5173243c09291e0a/sage_numerical_backends_coin-9.0b12.tar.gz

Development here:

See also:

Change History (69)

comment:1 follow-up: Changed 15 months ago by dcoudert

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 ?

comment:2 in reply to: ↑ 1 Changed 15 months ago by mkoeppe

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 11 months ago by mkoeppe

  • Description modified (diff)
  • Milestone changed from sage-wishlist to sage-9.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 11 months ago by mkoeppe

  • Cc isuruf saraedum fbissey added

comment:5 Changed 11 months ago by fbissey

For glpk it looks like https://github.com/biosustain/swiglpk/releases is the best maintained. Excluding sage and cvxopt.

comment:6 Changed 11 months ago by mkoeppe

  • Description modified (diff)

comment:7 Changed 11 months ago by mkoeppe

  • Description modified (diff)

comment:8 Changed 10 months ago by mkoeppe

  • 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/sage-numerical-backends-coin. It depends on Sage (as it inherits from sage.numerical.backends.generic_backend.GenericBackend).

comment:9 Changed 10 months ago by mkoeppe

  • 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 10 months ago by dimpase

Is there a git branch to try, replacing Sage's current COIN-OR backend with this one?

comment:11 Changed 10 months ago by mkoeppe

Not yet (working on it right now), but the 3 backends already pass their test suites separately.

comment:12 Changed 10 months ago by mkoeppe

  • Branch set to u/mkoeppe/move_optional_sage_optimization_backends_to_separate_cython_packages_to_remove_optionalextension_problems

comment:13 Changed 10 months ago by git

  • Commit set to 437fec50bb78832cd797f263f73732c6993c5719

Branch pushed to git repo; I updated commit sha1. New commits:

437fec5Fixup dependencies

comment:14 Changed 10 months ago by mkoeppe

Now the packages can be installed using sage -i -c... please test

comment:15 Changed 10 months ago by dimpase

remains of copypaste, I see PyNormaliz in the branch...

comment:16 Changed 10 months ago by git

  • Commit changed from 437fec50bb78832cd797f263f73732c6993c5719 to 846ca9a1520562f5c375db8c2ddf45ef5133956c

Branch pushed to git repo; I updated commit sha1. New commits:

846ca9aReplace CoinBackend, CPLEXBackend, GurobiBackend by their versions imported from sage_numerical_backends_*

comment:17 Changed 10 months ago by mkoeppe

  • Authors set to Matthias Koeppe
  • Status changed from new to needs_review

comment:18 Changed 10 months ago by git

  • Commit changed from 846ca9a1520562f5c375db8c2ddf45ef5133956c to 3c557b48cf069ebfb61fe757894808403ba74b1c

Branch pushed to git repo; I updated commit sha1. New commits:

3c557b4build/pkgs/sage_numerical_backends_*/spkg-install: Adjust error message

comment:19 Changed 10 months ago by git

  • Commit changed from 3c557b48cf069ebfb61fe757894808403ba74b1c to 84c83f26b23fe2714b9078e63e85bc45525cb896

Branch pushed to git repo; I updated commit sha1. New commits:

84c83f2src/doc/en/thematic_tutorials/linear_programming.rst: Update COIN/CPLEX/Gurobi install instructions

comment:20 Changed 10 months ago by git

  • Commit changed from 84c83f26b23fe2714b9078e63e85bc45525cb896 to 48287667e7c3178c6da2cf4e6171d353e2af60d7

Branch pushed to git repo; I updated commit sha1. New commits:

4828766MixedIntegerLinearProgram: Update docstrings for class and __init__, refer to thematic tutorial, and reduce copy-paste

comment:21 Changed 10 months ago by git

  • Commit changed from 48287667e7c3178c6da2cf4e6171d353e2af60d7 to 189d60bc565f05a3c72c76da8b2cabc863e08a4f

Branch pushed to git repo; I updated commit sha1. New commits:

189d60bget_solver: Reduce copy-paste in docstring

comment:22 Changed 10 months ago by mkoeppe

  • Cc tmonteil vdelecroix added

comment:23 Changed 10 months ago by mkoeppe

  • Description modified (diff)

comment:24 Changed 10 months ago by git

  • Commit changed from 189d60bc565f05a3c72c76da8b2cabc863e08a4f to 53f377414b94308b6ad3bfc41fdf4ff7545e0df5

Branch pushed to git repo; I updated commit sha1. New commits:

357e966src/doc/en/thematic_tutorials/linear_programming.rst: Update license info, URL for cbc
53f3774Update sage_numerical_backends_coin to 9.0b10

comment:25 Changed 10 months ago by tscrim

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 sage-devel, but I would just post something quick there to see if there are any objections.

comment:26 Changed 10 months ago by mkoeppe

They can't be standard packages because they only compile if the respective solvers are installed.

comment:27 Changed 10 months ago by mkoeppe

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 10 months ago by tscrim

Ah, I see. Sorry for the noise.

comment:29 Changed 10 months ago by fbissey

coin is problematic for me on sage-on-gentoo, 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 follow-up: Changed 10 months ago by 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/sage-numerical-backends-coin on sage installations such as the one provided on gentoo. My current test scripts (using GitHub actions) cover conda-forge so far, and I'm working on various debian/ubuntu flavors.

comment:31 Changed 10 months ago by mkoeppe

  • Description modified (diff)

comment:32 in reply to: ↑ 30 Changed 10 months ago by fbissey

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/sage-numerical-backends-coin on sage installations such as the one provided on gentoo. My current test scripts (using GitHub actions) cover conda-forge 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 10 months ago by mkoeppe

It just installs itself as a Python package named sage_numerical_backends_coin.coin_backend (note, underscores, not dots). The https://github.com/mkoeppe/sage-numerical-backends-coin/blob/master/README.md explains how to use it, including how to patch it into a sage for testing purposes.

comment:34 follow-up: Changed 10 months ago by dimpase

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  
    11tarball=sage_numerical_backends_coin-VERSION.tar.gz
    2 sha1=fd96cfc224f1f45bad6bacaaf37df3904fa7a561
    3 md5=98e5a002648cdf3167df2dafb16cde47
    4 cksum=869439056
     2sha1=0c424f8d01bdd44169630bc898738a4ee146ea2c
     3md5=09b6b74d7c8b9b3526424cf8850f8700
     4cksum=1339126990
  • build/pkgs/sage_numerical_backends_coin/package-version.txt

    diff --git a/build/pkgs/sage_numerical_backends_coin/package-version.txt b/build/pkgs/sage_numerical_backends_coin/package-version.txt
    index 5d6a14cdd9..1700f7be00 100644
    a b  
    1 9.0b10
     19.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 follow-up: Changed 10 months ago by dimpase

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 follow-up: Changed 10 months ago by 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.

comment:37 Changed 10 months ago by dimpase

in the environment as above for coin,

SAGE_CHECK=yes ./sage -f sage_numerical_backends_gurobi

fails with

...
[sage_numerical_backends_gurobi-9.0b9] Running the test suite for sage_numerical_backends_gurobi-9.0b9...
[sage_numerical_backends_gurobi-9.0b9] running test
[sage_numerical_backends_gurobi-9.0b9] Searching for sage-package
[sage_numerical_backends_gurobi-9.0b9] Reading https://pypi.org/simple/sage-package/
[sage_numerical_backends_gurobi-9.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_gurobi-9.0b9] Download error on https://pypi.org/simple/sage-package/: [Errno 110] Connection timed out -- Some packages may not be found!
[sage_numerical_backends_gurobi-9.0b9] Couldn't find index page for 'sage-package' (maybe misspelled?)
[sage_numerical_backends_gurobi-9.0b9] Scanning index of all packages (this may take a while)
[sage_numerical_backends_gurobi-9.0b9] Reading https://pypi.org/simple/
[sage_numerical_backends_gurobi-9.0b9] Download error on https://pypi.org/simple/: [Errno 110] Connection timed out -- Some packages may not be found!
[sage_numerical_backends_gurobi-9.0b9] No local packages or working download links found for sage-package
[sage_numerical_backends_gurobi-9.0b9] error: Could not find suitable distribution for Requirement.parse('sage-package')
[sage_numerical_backends_gurobi-9.0b9] 
[sage_numerical_backends_gurobi-9.0b9] real     1m4.289s
[sage_numerical_backends_gurobi-9.0b9] user     0m0.833s
[sage_numerical_backends_gurobi-9.0b9] sys      0m0.148s
[sage_numerical_backends_gurobi-9.0b9] ************************************************************************
[sage_numerical_backends_gurobi-9.0b9] Error testing package sage_numerical_backends_gurobi-9.0b9

comment:38 in reply to: ↑ 34 ; follow-up: Changed 10 months ago by 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.

comment:39 in reply to: ↑ 35 Changed 10 months ago by mkoeppe

Replying to dimpase:

Where are the tests from now gone sage/numerical/backends/coin_backend.pyx ? Are they all being run while installing with SAGE_CHECK=yes ?

They are here: https://github.com/mkoeppe/sage-numerical-backends-coin/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 10 months ago by dimpase

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/sage-numerical-backends-coin/#files says it made it there ~10 hours ago.

comment:41 follow-up: Changed 10 months ago by mkoeppe

  • Description modified (diff)

Created follow-up ticket, cleaned up ticket description

comment:42 in reply to: ↑ 41 ; follow-up: Changed 10 months ago by dimpase

Replying to mkoeppe:

Created follow-up ticket, cleaned up ticket description

some links to packages are not up to date.

comment:43 in reply to: ↑ 36 Changed 10 months ago by mkoeppe

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 10 months ago by mkoeppe

Replying to dimpase:

Replying to mkoeppe:

Created follow-up ticket, cleaned up ticket description

some links to packages are not up to date.

Thanks for testing! I'll update the cplex and gurobi packages with my changes to the coin package and then make new releases.

comment:45 follow-up: Changed 10 months ago by dimpase

Perhaps Gurobi (and similarly, CPLEX) can get some spkg-configure.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 --with-gurobi-home= option which would default to $GUROBI_HOME, and GUROBI_HOME should be written in sage-env-config etc.

This is for a follow-up ticket, of course.

comment:46 in reply to: ↑ 45 ; follow-up: Changed 10 months ago by mkoeppe

Replying to dimpase:

Perhaps Gurobi (and similarly, CPLEX) can get some spkg-configure.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 --with-gurobi-home= option which would default to $GUROBI_HOME, and GUROBI_HOME should be written in sage-env-config etc.

This is for a follow-up ticket, of course.

The macOS installer of Gurobi adds the following symlinks:

lrwxr-xr-x  1 root  wheel  40 Apr 28  2016 /usr/local/bin/gurobi.env -> //Library/gurobi651/mac64/bin/gurobi.env
lrwxr-xr-x  1 root  admin  39 Dec 24 12:11 /usr/local/bin/gurobi.sh -> //Library/gurobi900/mac64/bin/gurobi.sh
lrwxr-xr-x  1 root  admin  39 Dec 24 12:11 /usr/local/bin/gurobi_cl -> //Library/gurobi900/mac64/bin/gurobi_cl

See https://github.com/mkoeppe/sage-numerical-backends-gurobi/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 10 months ago by mkoeppe

Replying to mkoeppe:

Replying to dimpase:

Perhaps Gurobi (and similarly, CPLEX) can get some spkg-configure.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 --with-gurobi-home= option which would default to $GUROBI_HOME, and GUROBI_HOME should be written in sage-env-config etc.

This is for a follow-up ticket, of course.

The macOS installer of Gurobi adds the following symlinks:

lrwxr-xr-x  1 root  wheel  40 Apr 28  2016 /usr/local/bin/gurobi.env -> //Library/gurobi651/mac64/bin/gurobi.env
lrwxr-xr-x  1 root  admin  39 Dec 24 12:11 /usr/local/bin/gurobi.sh -> //Library/gurobi900/mac64/bin/gurobi.sh
lrwxr-xr-x  1 root  admin  39 Dec 24 12:11 /usr/local/bin/gurobi_cl -> //Library/gurobi900/mac64/bin/gurobi_cl

See https://github.com/mkoeppe/sage-numerical-backends-gurobi/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 follow-up: Changed 10 months ago by dimpase

Even on a Mac, with a multi-user installation one might want to hardcode GUROBI_HOME and the license file location (GRB_LICENSE_FILE).

comment:49 Changed 10 months ago by mkoeppe

  • Description modified (diff)

comment:50 Changed 10 months ago by git

  • Commit changed from 53f377414b94308b6ad3bfc41fdf4ff7545e0df5 to 7caa365e427860e2b91387e014ef8d2ed06e16aa

Branch pushed to git repo; I updated commit sha1. New commits:

7caa365Update sage_numerical_backends_gurobi and sage_numerical_backends_coin to 9.0b12

comment:51 Changed 10 months ago by mkoeppe

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/sage-numerical-backends-gurobi/blob/master/README.md

comment:52 in reply to: ↑ 48 Changed 10 months ago by mkoeppe

Replying to dimpase:

Even on a Mac, with a multi-user 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 10 months ago by mkoeppe

  • Description modified (diff)

comment:54 Changed 10 months ago by git

  • Commit changed from 7caa365e427860e2b91387e014ef8d2ed06e16aa to 2110ed3270741ec5f7211068ebbb91a787f4d815

Branch pushed to git repo; I updated commit sha1. New commits:

2110ed3Update sage_numerical_backends_cplex to 9.0b12

comment:55 Changed 10 months ago by mkoeppe

Just updated the cplex backend. Ready for review.

comment:56 follow-up: Changed 10 months ago by isuruf

I suggest using a namespace package for this. See https://packaging.python.org/guides/packaging-namespace-packages/

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="COIN-OR 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', 'linear-programming', '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 10 months ago by mkoeppe

Replying to isuruf:

I suggest using a namespace package for this. See https://packaging.python.org/guides/packaging-namespace-packages/

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 follow-ups: Changed 10 months ago by isuruf

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 10 months ago by mkoeppe

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 ; follow-up: Changed 10 months ago by mkoeppe

Thanks for the pull request at https://github.com/mkoeppe/sage-numerical-backends-coin/pull/4 . Let's continue the discussion regarding namespace packages there.

comment:61 Changed 10 months ago by git

  • Commit changed from 2110ed3270741ec5f7211068ebbb91a787f4d815 to 127989764d490e3d9359712970923bd993b14067

Branch pushed to git repo; I updated commit sha1. New commits:

1279897build/pkgs/sage_numerical_backends_*/dependencies: Add some .pxd and .h as dependencies

comment:62 in reply to: ↑ 60 Changed 10 months ago by mkoeppe

Replying to mkoeppe:

Thanks for the pull request at https://github.com/mkoeppe/sage-numerical-backends-coin/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 10 months ago by mkoeppe

  • Cc slabbe added

comment:64 Changed 10 months ago by dimpase

  • Milestone changed from sage-9.0 to sage-9.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 10 months ago by dimpase

  • Status changed from needs_review to positive_review

comment:66 Changed 10 months ago by mkoeppe

Thank you!

comment:67 Changed 10 months ago by vbraun

  • 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 follow-up: Changed 10 months ago by slabbe

  • 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 10 months ago by mkoeppe

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.

Note: See TracTickets for help on using tickets.