Add Astropy to default UMR blacklist for Python 2.7 due to resulting bug

[pllim]

Problem Description

Need a place to document known Spyder issue with Astropy. There is a PR at astropy/astropy#7374 but we feel it belongs more to your documentation over here. Please advise.

What steps will reproduce the problem?

Detailed description at astropy/astropy#7363

What is the expected output? What do you see instead?

Expect no error message. Instead, there is error message.

Package Versions

• Spyder: 2.3.5.2 - 3.1.2
• Python: 2.7
• Qt: N/A
• PyQt: N/A
• Operating System: openSUSE Leap 42.3

Dependencies

N/A

[CAM-Gerlach]

Thanks for the information and request. The place to put it currently would be our Troubleshooting Guide and FAQ on our wiki, where we list common known issues and solutions (although it is currently more focused on general troubleshooting, it is in the slow process of being expanded).

However, I note both here and skimming the attached thread, the problem exists only with

Spyder: 2.3.5.2 - 3.1.2

Those Spyder versions are many years old and long-unsupported; the current stable version is 3.2.8; with 3.3 in the immediate works and Spyder 4 as the development version. Therefore, if the issue isn't present in the current version (or at least something very near it), we can only advise that users update to the supported stable release; due to the current funding situation we simply cannot spare the resources supporting versions that are many years old, unfortunately.

Therefore, please advise accordingly. Thanks!

[dhomeier]

Thanks for looking into this; I have confirmed the problem under MacOS 10.12 and Python 2.7 (it does not occur in 3.5 or higher) for

spyder 3.2.8
qtpy 1.3.1
pyqt5 5.10.1
astropy 2.0.5

as long as astropy is not among the blacklisted modules, i.e. actually reloaded by sitecustomize.UserModuleReloader. I have tested a similar script reloading the scipy, pandas and pytables packages, and none of the latter raises an exception.

[CAM-Gerlach]

Okay, thanks for following up @dhomeier . Pardon my ignorance, but is the reason Spyder is detecting it as a "user module" and even trying to reload it is that you're actively developing and modifying it from e.g. a git clone, vs. having it installed normally as most users would? My understanding is that UMR shouldn't even try to trigger if there are no changes to the module and it is properly installed as a third party package vs. just being on the path/in the working directly (I don't know the exact logic off the top of my head). @ccordoba12 ?

[ccordoba12]

@pllim, @dhomeier, what if we simply add astropy among our list of default blacklisted modules for Python 2.7?

We can certainly add a note in our docs, but I doubt people would easily find it.

[dhomeier]

@CAM-Gerlach, in the original bug report the user was running the Spyder version (3.1.4) installed on her Ubuntu 17.10 system with a user installation of Astropy in ~/.local/lib (probably in some way like pip install --user). Since Astropy versions included with most distributions are often even more out of date than Spyder, if they exist at all, this is probably not a too uncommon situation.
If not blacklisted, the UMR reloads the imported astropy modules in any case, even if they have not been changed since the first runfile().

[dhomeier]

@ccordoba12, yes, I think that would be a helpful workaround - active astropy development is under Python 3 only anyway, and in any case is should be safer to start a new IPython kernel for testing.

[CAM-Gerlach]

Thanks for the explanation @dhomeier . I guess I can be a little too conda centric sometimes, heh.

should be safer to start a new IPython kernel for testing.

Just in case you're curious about the various ways to quickly achieve this in Spyder, I refer you to the recent #6955 .

[ccordoba12]

@dalthviz, please work on this one.