Install Sage on Travis using conda-forge#14703
Conversation
(Hopefully) fixes sympy#13395.
Move it to the Python 2.7 optional dependency build, which isn't in allowed_failures. If the conda install works, it shouldn't fail any more.
|
Test failure. Looks like an issue with the sage package. CC @isuruf |
|
It also occurs to me that sage is going to install SymPy, so we should probably remove it before continuing to make sure the conda SymPy isn't used in the tests. |
|
Now it fails with +sage -t sympy/external/tests/test_sage.py
Traceback (most recent call last):
File "/home/travis/miniconda/envs/test-environment/bin/sage-runtests", line 124, in <module>
DC = DocTestController(options, args)
File "/home/travis/miniconda/envs/test-environment/lib/python2.7/site-packages/sage/doctest/control.py", line 331, in __init__
for pkg in list_packages('optional', local=True).values():
File "/home/travis/miniconda/envs/test-environment/lib/python2.7/site-packages/sage/misc/package.py", line 226, in list_packages
installed = installed_packages(exclude_pip)
File "/home/travis/miniconda/envs/test-environment/lib/python2.7/site-packages/sage/misc/package.py", line 288, in installed_packages
installed.update(pkgname_split(pkgname) for pkgname in os.listdir(SAGE_SPKG_INST))
OSError: [Errno 2] No such file or directory: '/home/travis/miniconda/envs/test-environment/var/lib/sage/installed'Is this the same issue described here #13395 (comment)? |
|
No this is being worked on by @saraedum at https://github.com/conda-forge/sagelib-feedstock/pull/20/files for sage-8.2. sage-8.3 has built in support I think. |
That way we don't accidentally test against it. SymPy will be installed because of Sage.
|
Great. Ping me when this is ready to test again. |
|
@asmeurer, it should be fixed now. |
|
Still the same error. |
|
It's installing |
|
Usually that means that the version you want has incompatible dependencies. If you have Linux, you can try running the conda install ( |
|
|
|
Ah. We should try to see if we can update cython. We should be testing against the latest versions of things anyway. |
|
There are some updates in the feedstock pull requests https://github.com/conda-forge/autowrap-feedstock/pulls. I wonder if we can remove the pin. |
Miniconda-latest is an ancient version of miniconda.
|
Still the same error. |
|
It's still using the old sagelib build. Don't know why |
|
It looks like it is able to install the correct sage this time. But now the build is running out of disk space! How much disk space do you get on Travis? Is there a simple way we can remove some stuff we don't need to free some up? |
|
So it looks like Travis has a dynamic disk space limit, which means this issue could disappear and reappear intermittently. We could probably ask them for more space, or figure out how to clear a chunk of the preinstalled stuff that we don't need (is it possible to use But first it would be nice to know if this is even going to work at all. If not we need to stick with the PPA approach, or do something else. |
|
Latest sage package is lighter and works. Now the error is, |
|
My guess is that it's trying to use the SymPy that comes with sage rather than the dev version, although I did try to avoid this scenario by conda removing sympy from the environment. The function in question was added after the last release. |
|
Not sure if this helps. I know that mpmath switches to the |
|
That is almost certainly the problem thanks. |
|
The problem is that mpmath's to_rational returns a Sage Integer, which we then pass to the gmpy backend, and it fails. I can fix it, but there are likely other places where this would pop up too. Should we actually be running all the tests with sage installed? I guess this issue would crop up even just using SymPy in sage, assuming sage also includes gmpy2. |
|
I didn't realize the sage conda-forge packages were available for Mac too. I'll install it and see if I can find any other test failures. By the way, the llvmlite and theano garbage from the tests are there in master too. |
|
It doesn't work on my Mac |
|
Can you open an issue in https://github.com/conda-forge/sagelib-feedstock? |
When Sage is installed, mpmath uses it as a backend. This causes problem when Sage integers are passed to gmpy functions, which only work with Python ints, gmpy ints, or strings.
|
I got it working on my Mac. There are a lot of test failures. Some of them are because gmpy's mpq/mpz do not accept Sage Integers, which mpmath uses when Sage is installed. I have pushed a fix that fixes at least some of those issues (I still need to run the full test suite to see if they are all fixed). There are also some issues where things are giving different answers: I guess somehow the Sage backend in mpmath has some different rounding. Some upstream questions:
Also, should we try to run the full test suite with Sage installed? I don't want to create four more matrix builds. |
Probably. Both use |
|
I think gmpy integers are a little faster actually, but what matters is that the Sage backend has mpf/mpc types and a bunch of other code implemented entirely in Cython. These days it would be better (much faster than either) to write a standalone backend using Arb. |
|
Looks like the Sage backend to mpmath uses many of its own functions. For instance, we have this test: # This looses a binary digit of precision, so it isn't equal to the above,
# but check that it normalizes correctly
x2_hex = Float((0, long(0x13333333333333)*2, -53, 53))
assert x2_hex._mpf_ == (0, 5404319552844595, -52, 52)
# XXX: Should this test also hold?
# assert x2_hex._prec == 52With the Sage backend, it fails (the result is |
|
Full list of failures: |
|
And doctest failures: |
|
By the way, it looks like Sage does some funny stuff when it is imported (it adds a signal handler for Ctrl-C, don't know what else it does). It's probably a good idea to install it only in a separate conda environment for local development. |
|
Sage's mpf type doesn't subclass from mpmath's mpnumeric, which makes it so that I'm unsure which of these issues we should try to work around and which should just be considered upstream sage, mpmath, and/or gmpy issues. |
Mpmath using the Sage backend causes issues throughout SymPy, which are generally bugs with upstream Sage, mpmath, and/or gmpy2 (see sympy#14703). Also we would really need to be running the full test suite with Sage installed to be catching all of these (TEST_OPT_DEPENDENCY where the Sage tests are run only runs a subset of the test suite).
|
Also part of me just wants to set |
|
On Wed, May 23, 2018 at 1:12 PM, Aaron Meurer ***@***.***> wrote:
I got it working on my Mac.
There are a lot of test failures. Some of them are because gmpy's mpq/mpz
do not accept Sage Integers, which mpmath uses when Sage is installed. I
have pushed a fix that fixes at least some of those issues (I still need to
run the full test suite to see if they are all fixed).
There are also some issues where things are giving different answers:
___________________________________________________ sympy/holonomic/tests/test_holonomic.py:test_evalf_rk4 ___________________________________________________
File "/users/aaronmeurer/documents/python/sympy/sympy/sympy/holonomic/tests/test_holonomic.py", line 407, in test_evalf_rk4
assert sstr(p.evalf(r)[-1]) == s
AssertionError:
0.909294635227854 + 4.73926453636864e-15*I ==
0.90929463522785 + 1.52655665885959e-16*I
I guess somehow the Sage backend in mpmath has some different rounding.
Some upstream questions:
- Why does mpmath prefer sage to gmpy when both are installed? Are
Sage Integers really faster than gmpy integers?
- Shouldn't mpq work with any input that can be converted to int.
According to #12895 (comment)
<#12895 (comment)>,
this might be already fixed in a newer version of gmpy2 after 2.0.8 (which
hasn't been released yet according to PyPI). CC @casevh
<https://github.com/casevh>
The new version of PyPi won't display any results for the gmpy2 2.1
series. I'm guessing that PyPi decided to hide alpha releases. Here is the
direct link to the latest alpha release:
https://pypi.org/project/gmpy2/2.1.0a2/
The new version includes hooks for conversion to/from Sage types so it
should address some of your issues. If not, I'll follow this thread or just
include me on another thread.
…
Also, should we try to run the full test suite with Sage installed? I
don't want to create four more matrix builds.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#14703 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABkdb-7ztrrTh18mclTytcHJZFEz5H3Cks5t1cLIgaJpZM4T3KpQ>
.
|
|
With 2.1.0a2 I get the same issue: >>> gmpy2.mpq(sage.all.Integer(2), sage.all.Integer(3))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: mpq() requires numeric or string argument
>>> gmpy2.version()
'2.1.0a2' |
Python 2 doesn't show chained exceptions, so this is needed to see the real error on Travis.
This reverts commit b8b83b3.
|
I've fixed this by making it so that mpmath only uses the sage backend for the sage tests. If someone wants to try to fix (workaround) the upstream issues that are caused when it is used for the full test suite, go ahead. But as far as I'm concerned, this PR is ready to go. |
|
Upstream Sage issue https://trac.sagemath.org/ticket/25445 |
(Hopefully) fixes #13395.