AttributeError: module 'mpmath' has no attribute 'rational'

[ravi160822]

File "/usr/local/lib/python3.11/site-packages/torch-2.0.0-py3.11-linux-x86_64.egg/torch/_guards.py", line 14, in
import sympy # type: ignore[import]
^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/sympy-1.12-py3.11.egg/sympy/init.py", line 30, in
from sympy.core.cache import lazy_function
File "/usr/local/lib/python3.11/site-packages/sympy-1.12-py3.11.egg/sympy/core/init.py", line 9, in
from .expr import Expr, AtomicExpr, UnevaluatedExpr
File "/usr/local/lib/python3.11/site-packages/sympy-1.12-py3.11.egg/sympy/core/expr.py", line 4159, in
from .mul import Mul
File "/usr/local/lib/python3.11/site-packages/sympy-1.12-py3.11.egg/sympy/core/mul.py", line 2193, in
from .numbers import Rational
File "/usr/local/lib/python3.11/site-packages/sympy-1.12-py3.11.egg/sympy/core/numbers.py", line 4567, in
_sympy_converter[type(mpmath.rational.mpq(1, 2))] = sympify_mpmath_mpq
^^^^^^^^^^^^^^^
AttributeError: module 'mpmath' has no attribute 'rational'

[oscarbenjamin]

What version of mpmath are you using?

[ravi160822]

seems the issue appeared as mpmath made a new release on 23-Feb-2024, https://pypi.org/project/mpmath/#history, I have made the version to 1.3.0 again, it is working fine now.
But by default it installed 1.4.0a0.

[oscarbenjamin]

That release is an alpha prerelease. It should only get installed if you opt in somehow e.g. by passing --pre to pip.

How did you end up having mpmath 1.4.0a0?

[WeizhuoZhang-intel]

In pytorch installation step, use python setup.py develop to build pytorch will install mpmath 1.4.0a0.

#13 666.7 Searching for mpmath>=0.19
#13 666.7 Reading https://pypi.org/simple/mpmath/
#13 666.7 Downloading https://files.pythonhosted.org/packages/bf/43/28116b6ad78fcf009071a12f702aeae6c9fbc2cfd814c5eefaacda1a52aa/mpmath-1.4.0a0-py3-none-any.whl#sha256=1b60ef0e9ea0e13e11580e31dc0c47284b9a26b1384bcef577ddda5e29b2836b
#13 666.8 Best match: mpmath 1.4.0a0
#13 666.8 Processing mpmath-1.4.0a0-py3-none-any.whl
#13 666.8 Installing mpmath-1.4.0a0-py3-none-any.whl to /opt/conda/lib/python3.8/site-packages
#13 666.8 Adding mpmath 1.4.0a0 to easy-install.pth file
#13 666.8 detected new path './MarkupSafe-2.1.5-py3.8-linux-x86_64.egg'
#13 666.8 
#13 666.8 Installed /opt/conda/lib/python3.8/site-packages/mpmath-1.4.0a0-py3.8.egg
#13 666.8 Searching for typing-extensions==4.9.0
#13 666.8 Best match: typing-extensions 4.9.0
#13 666.8 Adding typing-extensions 4.9.0 to easy-install.pth file
#13 666.8 detected new path './mpmath-1.4.0a0-py3.8.egg'
#13 666.8 
#13 666.8 Using /opt/conda/lib/python3.8/site-packages
#13 666.8 Finished processing dependencies for torch==2.3.0a0+git53f5035

[ravi160822]

yes same I installed torch, I did not specifically install mpmath, it took the latest one by default, and import torch failed

now I have mentioned mpmath==1.3.0, and it is working fine, but someone else might also face the same issue.

[oscarbenjamin]

Which version of SymPy is being used and why is python setup.py develop being used?

The modern version of python setup.py develop is pip install -e .:
https://packaging.python.org/en/latest/discussions/setup-py-deprecated/

[oscarbenjamin]

The AttributeError was fixed in gh-26269.

[oscarbenjamin]

The modern version of python setup.py develop is pip install -e .:

Note that this does make a difference because develop uses easy_install which installs prereleases whereas pip does not install prereleases by default.

Which version of SymPy is being used

I'm asking this because I can only presume that reason for using develop is that sympy is being installed from git rather than from the PyPI wheels. If this is using the latest commit from git then it should already be fixed after gh-26269.

[WeizhuoZhang-intel]

Which version of SymPy is being used and why is python setup.py develop being used?

The modern version of python setup.py develop is pip install -e .: https://packaging.python.org/en/latest/discussions/setup-py-deprecated/

The python setup.py develop is for building PyTorch, not SymPy. Pytorch will install its dependencies through pip, such as SymPy

[oscarbenjamin]

Pytorch will install its dependencies through pip, such as SymPy

Then why is the mpmath pre-release being installed? It won't be installed by pip unless --pre is being passed.

[ezyang]

@rgommers @asmeurer can sympy make a release to work with the newest mpmath? It seems like it's affecting many projects in the DL ecosystem

[oscarbenjamin]

We are planning a sympy release ASAP but there are a few issues that need to be resolved first.

Those projects in the DL ecosystem should fix their build configuration in any case though. It is not the newest mpmath but rather a prerelease of mpmath (1.4 alpha 0). If you always install the earliest prereleases of all transitive dependencies then this kind of breakage should be expected.

Any projects using python setup.py develop should change to using pip install -e . which would not install the mpmath prerelease. Using python setup.py develop is deprecated:
https://packaging.python.org/en/latest/discussions/setup-py-deprecated/

[rgommers]

This does indeed look pretty disruptive, so a SymPy release soon will be quite helpful (I'm not a SymPy dev, so I'll leave that part to @oscarbenjamin and @asmeurer).

There are a couple of issues on the PyTorch side that make it way too likely that pre-releases of dependencies get pulled in. I commented on that in pytorch/pytorch#120995 (comment). Fixing that up should mitigate the problem quickly, because it's all about building from source and installing nightlies with --pre - current released versions of PyTorch don't have a problem.

[rgommers]

@moorepants with all due respect, I think you misunderstand the problem just slightly here. If you add the upper bound, you only have hypothetical issues with some user who cannot use the versions of sympy and mpmath that were compatible at release time (why? some new feature in a dev version or the very latest mpmath that the user must really have, while at the same time an issue in latest sympy that prevents an upgrade?). While if the upper bound is added, it demonstrably prevents many real-world issues right now, and known incompatibilities that are certain to break pip install sympy==1.12 with a future mpmath release like Oscar pointed out.

I can tell you from long-time experience in managing the upper bounds that scipy puts on numpy every release: this works fine and prevents lots of problems, while causing very few issues. The reality is that if you have a transitive dependency as a package author, you have to carefully manage it. "don't use an upper bound" is an excellent default, but a "never add any bounds ever" stance is a little dogmatic and far from optimal.

[moorepants]

Thanks Ralf. I don't think I misunderstand this aspect, but surely may be misunderstanding other things. I am very much concerned about hypothetical installation issues that may occur if an upper bound is added to dependencies of SymPy. My objection to having upper bound pins is specifically this hypothetical, but regular and real, issue.

If we have patched SymPy 1.12 and SymPy current master to work with mpmath 1.4a01, then why would an upper bound be needed? If we haven't patched SymPy with the fix, then I can see how an upper bound could be used to ensure SymPy 1.12.1 works with mpmath 1.4a01 (and likely the upcoming 1.4).

Let's say mpmath 1.4 is released today. Then all prior released SymPy versions are broken when installed with mpmath 1.4.0. If I am a user of any of these prior releases of SymPy, then I would have to at least do something like this pip install sympy mpmath<1.4 to have a working environment. As far as I can tell, that is what everyone already has done that depends on pytorch nightly. If SymPy never releases again, then SymPy users are stuck with mpmath <1.4 forever.

But now that mpmath 1.4 is out, SymPy can make a release that is compatible with mpmath 1.1.0 to and including 1.4. This is SymPy 1.12.1. Now as a user I can install SymPy with mpmath 1.4 (but only SymPy >= 1.12.1). We could also release this bugfix to as many prior versions of SymPy (1.11, 1.10, ...) as we desire so that users can use many versions of SymPy with mpmath 1.4. When we release SymPy 1.13, it also includes the patch, so it works with mpmath 1.1.0-1.4. As far as I understand, the issue would be solved at this point without any upper bound pins. (maybe my misunderstanding is here)

Now if our SymPy 1.12.1 has an upper bound of mpmath >=1.1.0,<=1.4 and a new mpmath 1.5 comes out, then I cannot install mpmath 1.5 with SymPy 1.12.1 even though it may work with SymPy 1.12.1. If we leave the upper bound off mpmath dependency, then this never occurs.

As far as having a tight release coupling between mpmath and sympy (like numpy and scipy), that's fine if we can arrange it, but I don't think that is currently the case. The recent changes were made to mpmath without deprecation (as far as I understand).

[oscarbenjamin]

Again, if we are actually able to be on top of releases, including patch and backport releases, it doesn't matter a whole lot because we can fix whatever issues arise as they come up,

A new patch release cannot fix it so that pip install sympy==1.12 works because if the 1.12 release has no version caps then that cannot be changed retrospectively. Being on top of releases means that we can regularly update the version caps. If there are no version caps though then all of those releases will ultimately break once new enough versions of mpmath are available.

[moorepants]

A new patch release cannot fix it so that pip install sympy==1.12 works because if the 1.12 release has no version caps then that cannot be changed retrospectively.

Maybe this hits the difference in views on this. I would never expect that to work some time further in the future without carefully pinning sympy's dependencies in the install command, i.e. you have to type pip install sympy==1.12 mpmath==1.3.0.

[rgommers]

Maybe this hits the difference in views on this. I would never expect that to work some time further in the future without carefully pinning sympy's dependencies in the install command, i.e. you have to type pip install sympy==1.12 mpmath==1.3.0.

I think that that is indeed the difference. I fully expect this to work, and my goal as a package author is to make sure it does. It can be done with few downsides.

Basically, the problem is: if sympy doesn't manage its runtime dependency on mpmath, then every package author and end user that depends on sympy will have to do manage that dependency for themselves instead (unless they're never trying to use anything but the very latest sympy release, which isn't realistic).

[oscarbenjamin]

you have to type pip install sympy==1.12 mpmath==1.3.0.

How would you know in future which versions of mpmath are compatible with each sympy release if the sympy package metadata has no version caps?

Bear in mind that downstream projects might have larger dependency trees than just sympy and mpmath e.g. pytorch has something like 25 transitive dependencies.

[moorepants]

Basically, the problem is: if sympy doesn't manage its runtime dependency on mpmath, then every package author and end user that depends on sympy will have to do manage that dependency for themselves instead (unless they're never trying to use anything but the very latest sympy release, which isn't realistic).

Yes, absolutely correct, but only if you are trying to install very old versions. Every time I've tried to install old Python packages over the last 20 years, this is exactly what I have to do. I don't want to measure how much time I used to spend getting an old version of Plone running, even with the == pinning in zc.buildout. I would say it isn't realistic to expect old software to install without careful attention even if the developer tried to future proof it in some way. These upper bound pins are a relatively new phenomena in Python land, with poetry and pushes for semantic versioning bringing them about.

How would you know in future which versions of mpmath are compatible with each sympy release if the sympy package metadata has no version caps?

You don't know this, at least not from any information in the source tarball because the code was released in real time before any future dependencies that may have broken it. You can usually deduce this from other historical artifacts and yes it is more painful if the dependency stack is deep.

I do agree that you can manage upper bound pins without the detrimental effects to users, but you really have to be on top of things because you are always leaving guaranteed incompatible software out in the wild. Without upper bound pins you are only leaving might-be-incompatible software out in the wild. Oscar dismissed me posting Henry Schreiner's blog post earlier, but I don't really know how to articulate the rational behind avoiding upper bounds better than what he wrote: https://iscinumpy.dev/post/bound-version-constraints/. Apologies if you'd already read it.

[oscarbenjamin]

By the way it is possible to force install of versions that violate the dependency constraints using e.g. pip's --no-deps. For example on Python 3.8 you can do:

$ pip install --no-deps 'numpy==1.18' 'scipy==1.10'
Collecting numpy==1.18
  Using cached numpy-1.18.0-cp38-cp38-manylinux1_x86_64.whl.metadata (2.1 kB)
Collecting scipy==1.10
  Using cached scipy-1.10.0-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.metadata (58 kB)
Using cached numpy-1.18.0-cp38-cp38-manylinux1_x86_64.whl (20.6 MB)
Using cached scipy-1.10.0-cp38-cp38-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (34.5 MB)
Installing collected packages: scipy, numpy
Successfully installed numpy-1.18.0 scipy-1.10.0

Likewise uv has the concept of dependency overrides for this:
https://github.com/astral-sh/uv?tab=readme-ov-file#dependency-overrides

[moorepants]

The uv dependency overrides is a helpful feature. Nice idea. It helps avoid having to create things like this: https://pypi.org/project/poetry-relax/

[oscarbenjamin]

Oscar dismissed me posting Henry Schreiner's blog post earlier, but I don't really know how to articulate the rational behind avoiding upper bounds better than what he wrote: https://iscinumpy.dev/post/bound-version-constraints/. Apologies if you'd already read it.

I have read this excellent blog post by @henryiii before but I am not going to read the whole thing again right now because it is long. The blog post is aimed at a proliferation of speculative upper bounds as is encouraged by certain tools like poetry. That is absolutely not the situation here for us though.

Apart from Python itself SymPy has one hard dependency which is mpmath. The two libraries are tightly coupled having originally been a single codebase that was later split into two separate libraries. This is why I compare the situation to that of numpy and scipy which are also tightly coupled and as I understand it were originally a single codebase as well.

The section in the blog post titled "Upper limits are valid sometimes" is the relevant part here and a number of reasons are given for when upper bounds might be the right choice many of which apply to this situation:

1. If a dependency is known to be broken, block out the broken version.

This is the situation for mpmath 1.4.0 alpha 0. It should not have mattered because it is a prerelease but the pytorch situation shows that we probably still need version caps to exclude prereleases as well. Currently we have released sympy 1.12.1 alpha 1 which is compatible with mpmath 1.4.0 alpha 0 but still has no version cap (actually it has mpmath >= 0.19 which is wildly inaccurate). So the situation as it stands now is that an mpmath 1.4.0 alpha 1 release could bring back the problem that lead to this issue being opened in the first place.

2. If you know upstream is about to make a major change that is very likely to break your usage, you can cap

I am not sure if mpmath 1.4.0 would make major changes but I do see major changes on the horizon for mpmath, like mpf tuples becoming 3-tuples and everything being rebuilt around python-flint's arf type. Focusing purely on how to improve mpmath I would want to make a lot of changes that would break sympy's current use of it.

5. You are releasing two or more libraries in sync with each other.

This is the situation with numpy and scipy and is somewhat similar to the situation with mpmath and sympy. They are not two unrelated projects and there is discussion and coordination. We will coordinate to ensure that the most recent releases of both projects are always compatible even if significantly older versions of one are not compatible with significantly newer versions of the other. We also can test supported versions of mpmath to keep any version constraints up to date.

6. You depend on private internal details of a library.

Most of the mpmath functions that sympy uses are not part of mpmath's documented public API. For example the entire mpmath.libmp subpackage is not documented at all and all of SymPy's evalf is based on those functions rather than the public API based on the mpf type and MPContext.

7. If you have a heavy dependency on a library, maybe cap

This is absolutely applicable to sympy and mpmath. I'm not sure if everyone understands exactly the extent to which core sympy functionality depends on mpmath because a lot of things that look like symbolic manipulation are actually based on evalf's robust numerics which depends entirely on mpmath. The mathematical definition of most sympy functions effectively lies in the mpmath codebase rather than sympy's.

It is important not to be over-zealous about something like "never use upper bound caps". It might be a good default message for many common situations but you always have to look on a case by case basis at these things. For the particular case of sympy and mpmath right now we absolutely need to have an upper version cap.

It would be good for sympy to reduce its dependence on mpmath internals. Sympy and mpmath should coordinate to work out what should be considered the public stable API of mpmath going forwards and to try to ensure that sympy only depends on that (see e.g. mpmath/mpmath#704). However sympy depends on mpmath so heavily that I think we would always need upper bound version caps regardless. We got away without any formal version constraints in recent years just because mpmath was not being actively developed but that is not the case any more.

[moorepants]

I don't appreciate continuing to be called dogmatic and overzealous. I do not believe I'm making personal quips in the other direction.

I understand that there may be a use for a dependency cap in some cases as per the blog post, but I don't see how it is here. If SymPy >= 1.12.1 is compatible with mpmath 1.1.0 to 1.4.0 alpha 0, then we are safe until mpmath makes new releases that includes new breaking changes without deprecation. What is the reason for the upper bound pin in this case? I described the scenario that is a negative consequence in this comment: #26273 (comment).

The fact that anyone here may be helping to develop mpmath and has intentions to make breaking changes in future releases is interesting and provides some insight. I also know that everyone here has an intention to really be on the ball about keeping these version pins correctly and duly updated regularly, but proposing a new paradigm in how mpmath and SymPy have a co-release pattern, cycle, and coordinated effort is probably suitable for a SYMPEP.

[oscarbenjamin]

If SymPy >= 1.12.1 is compatible with mpmath 1.1.0 to 1.4.0 alpha 0, then we are safe until mpmath makes new releases that includes new breaking changes without deprecation. What is the reason for the upper bound pin in this case?

I have explained this repeatedly: SymPy 1.12.1 will not be compatible with all future versions of mpmath. There is a good chance that the next release of mpmath would break SymPy 1.12.1 or if not the next release then the one after that. This is not a hypothetical because we already saw significant breakage in the first alpha release and we know that changes are needed for mpmath to move forwards.

It has not been a problem in recent years just because mpmath was basically dormant and had almost no changes or releases. SymPy reaches too heavily into mpmath for anyone to expect or ask that mpmath never does anything that would break old SymPy versions. We cannot update the version constraint retroactively so if we put out any release now without version constraints then that release (pip install sympy==1.12.1) will be broken by some not too distant future mpmath release.

SymPy's version constraints should not even allow a situation in which SymPy is using deprecated functionality from mpmath because mpmath is so core to SymPy that this is like SymPy using its own deprecated functionality.

We can talk about a SymPEP for the future but if you are saying that there should be one before we add the version constraint then that is basically just blocking anything from happening. We should be putting out two SymPy releases 1.12.1 and 1.13 right now but both are now blocked if a SymPEP is needed first.

I have spent much more time on this than I wanted to and I am not going to write a SymPEP right now. I am also not going to put out any releases without the mpmath upper cap. I wouldn't have sunk time adding any releases for 1.12.x if it wasn't for this mpmath issue: we could be releasing 1.13 right now instead.

This is because of a hypothetical future scenario in which someone wants to use a new version of mpmath with an old version of sympy (which they would still be able to do anyway if they wanted). In order to support that hypothetical scenario we then break much more realistic scenarios like someone wanting to install a particular version of sympy and expecting it to work. Most importantly we leave ourselves at risk of sudden immediate breakage rather than being able to manage compatibility one release at a time.

I do not want to repeat the situation from Tuesday night where suddenly it becomes urgent to put out a new release and I sink a whole day of work at an inconvenient time: there would have been no urgent problem if the latest release of sympy had had a version cap on mpmath. I have done the necessary work to prevent this happening again in future but now others are blocking me from completing that. If this situation arises again in future then I expect others to handle it.

I am going to drop out of this discussion now. I am not putting out any releases but I am also not going to waste more time discussing this because I am repeating myself in the face of generic objections to upper caps that ignore all of the details of this situation.

[moorepants]

I think we just disagree about this then. Different perspectives give a different take on whether these version caps are helpful or not. Here it is helpful for you the developer, in this specific case, to put up future protections on the time you feel obliged to give if mpmath has sudden breaking changes. But a package distribution maintainer, where SymPy is one small part, may also lose a day of work because we introduce upper bound pins. I certainly have lost many days due to dealing with upper bound pins in the packaging, distribution, and maintaining work I do. We've never had upper pins on SymPy's dependencies and the approach of fixing SymPy and releasing if a dependency breaks it has served us well for many years without the negative consequences of upper bound pins.

Maybe it is time for SymPy to be a bit more formal about roles and responsibilities so that we can distribute the load among the core developers better. It should not be that Oscar has to bear the whole load with tight time pressure in such a situation.

[henryiii]

The blog post is aimed at a proliferation of speculative upper bounds as is encouraged by certain tools like poetry. That is absolutely not the situation here for us though. ... The section in the blog post titled "Upper limits are valid sometimes" is the relevant part here and a number of reasons are given for when upper bounds might be the right choice many of which apply to this situation:

You are correct, the post is not meant to say you can't upper cap (except the Python version, which doesn't even work correctly if you upper cap) if you've thought about it and have a reason to. It does increase friction, but if there's a high chance the next version(s) will break you and you are willing to make releases shortly after the dependency does & keep the cap up to date, go ahead and cap.

[moorepants]

Thanks for comment Henry. I'm not fundamentally against upper pins. I personally use them when upstream code breaks my packages and I don't have time to actually fix the issue. I release a point release with a version cap, but with the intention to get rid of it as soon as I fix the issue. This seems to align with this from your post:

If you know upstream is about to make a major change that is very likely to break your usage, you can cap. But try to fix this as quickly as possible so you can remove the cap by the time they release. Possibly add development branch/release testing until this is resolved. ...

We learned of a breaking upstream change in the alpha release of mpmath (top of this issue). Oscar fixed the compatibility issue in our master branch and even released it already with SymPy 1.12.1 alpha. So this change will not break SymPy 1.12.1 or SymPy 1.13. So, if we've already fixed it, then a cap in the release of 1.12.1 does nothing but prevent future versions of mpmath installed alongside sympy 1.12.1.

Now as of several hours ago, mpmath has added the code back that was removed in their alpha release. So their second alpha will not even break SymPy 1.12, pointing towards mpmath 1.4 not breaking SymPy at all. We also, thanks to Oscar, have the compatibility fix in place for whenever mpmath removes the code after a deprecation cycle. Yet, it seems the intent is still to prevent people from installing mpmath>=1.4 alongside SymPy 1.12.1.

There are four points (I think) in support of upper pins on mpmath moving forward:

• pip install sympy==<specific version number> should work "forever": if sympy is installed with the only required dependency with just those two packages in the virtual environment and we added upper pins to mpmath, then yes I agree this would work as far out as a 10 year horizon or so. But the second you need other packages in this environment, the picture starts to change, particularly if you want to install one of the 500 dependents of mpmath or work with the 100k repositories that use mpmath directly
• mpmath may make changes that break sympy in upcoming releases: this has always been the case, but it just hasn't happened much, maybe it will happen more in the near future, but this doesn't change anything for us other than we need to be more on our toes
• mpmath is tightly coupled with sympy: this is true but we don't control both repos or make tandem releases. that could change but it isn't the reality now
• upper pins will reduce the chance we have to do an emergency fix like this past week: that is likely true

So it seems the tradeoff is this: either pip install sympy==<specific version> is made more likely to work as the future progresses or we prevent people from installing specific versions of sympy alongside versions of mpmath that were released after it. If being able to have the second scenario means that I have to type pip install sympy==<specific version mpmath=<compatible version> instead of pip install sympy==<specific version> in the future, then the former seems to be worth the gain of increased compatibility that no upper pins provide.

There are proponents that find having the opposite preferable. I don't see a way to decide on either scenario because it is opinion at that point about who has do deal with any issues related to whether an upper bound pin was there. I'm of the opinion that we, the SymPy developers, should bear the burden and try to reduce it for the downstream users, library/application maintainers, and downstream packagers (which are many). I believe the introduction of upper pins puts the burden downstream of us more than not having them, as that is the problem I've encountered the most.

It's just opinion about who should deal with the issues and I didn't do the work to fix the recent issues. My opinion lies with the issues I've had to deal with regarding upper bound pins as a user, library developer dependent on SymPy, and packager/distributor. So, given that it now seems like we are at opinion, have nothing more to say on this.

[oscarbenjamin]

We learned of a breaking upstream change in the alpha release of mpmath (top of this issue).

We actually learned of it much earlier than that. I pushed a fix 8 months before the alpha release but it got transformed beyond recognition (#25290) so I had to fix it again a month ago (#26269). The second time I made sure to add CI checks.

[oscarbenjamin]

@ezyang and other pytorch people is it going to cause a problem when SymPy puts out a 1.13.0rc1 release candidate?

The mpmath issue is resolved now. SymPy 1.12.1 has the mpmath < 1.4 requirement and also has the fix to work with latest mpmath master anyway. SymPy 1.13.0rc1 and master also both have the fix and 1.13.0rc1 will have the mpmath < 1.4 constraint as well.

There are a lot of changes though from SymPy 1.12 to 1.13:
https://github.com/sympy/sympy/wiki/Release-Notes-for-1.13

Normally I wouldn't worry about a prerelease breaking anything because the purpose of release candidates is to pick up early reports of downstream breakage but we don't expect them to be used in "production". The intended purpose of prereleases is that downstream dependents can have e.g. an optional CI job that tests against them or that some users/downstream will install and test out the prereleases when they are announced.

Basically I want to put out SymPy 1.13.0rc1 and then I am going on holiday and will not respond to any reports of problems for maybe a week. When prereleases are being used in the intended way that is fine because the whole idea is that you put them out and then wait some time to collect reports of problems. Here though it seems that somehow pytorch can be broken by SymPy putting out a prerelease because setup.py develop will apparently pull that prerelease in causing immediate problems for people who did not intend to test the prerelease.

Does pytorch still have a setup that will pull in prereleases of dependencies automatically?

Does pytorch have anything to constrain the SymPy version so that SymPy 1.13.x would not be picked up automatically?

Can someone test pytorch with current SymPy master (or the 1.13 release branch)?

I haven't put any prerelease on PyPI but you can install the 1.13 release branch from git with:

pip install git+https://github.com/sympy/sympy.git@1.13

I intend to push sympy 1.13.0rc1 to PyPI tomorrow and then I will be unavailable for at least a few days.

[oscarbenjamin]

The mpmath issue is resolved now.

I'm going to close this issue as fixed.

Can someone test pytorch with current SymPy master (or the 1.13 release branch)?

you can install the 1.13 release branch from git with:
pip install git+https://github.com/sympy/sympy.git@1.13

Regardless of how pytorch handles prereleases the sympy 1.13 final release is also coming soon and so it would be good for someone to test with pytorch so that we can fix any issues before final release.