Changes to `ssl` and `concurrent.futures` imports to allow `astropy` to run in `pyodide`

Description

pyodide is a Python distribution that runs in the browser and thus allows installation-free use of Python and many scientific/data-science packages. Pyodide is the base kernel of other projects such as jupyterlite that provide JupyterLab and similar environments that fully run in the browser. Try it out here!

astropy is packaged as part of pyodide, but currently doesn’t fully work because some standard-library imports fail in pyodide. In particular import ssl in

https://github.com/astropy/astropy/blob/41f023995fc2b533deeac84f6fa818a5df04c26e/astropy/utils/data.py#L15

and import concurrent.futures in

https://github.com/astropy/astropy/blob/41f023995fc2b533deeac84f6fa818a5df04c26e/astropy/utils/console.py#L17

causes errors in pyodide (basically because Python’s _ssl library and multiprocessing are not supported in the browser currently). Because these are difficult things to fix, I don’t think they will be fixed soon in pyodide. Because these utility modules are imported elsewhere, they make it that one cannot use things like astropy.coordinates in pyodide. For example, type import astropy.coordinates in the pyodide REPL!

I just submitted a PR (now merged) to pyodide patching the current release of astropy to move the offending imports into the few functions that use them. With those patches, all astropy sub-modules can be imported and at least basicastropy.coordinates use works (I haven’t done a comprehensive test, but everything I’ve tried that I think should work, works now). This should soon (maybe an hour from now?) be available in the latest version, which you can run here!

To avoid having to do these patches for each new astropy release, it would be good to fix the issue here. I’m happy to submit a PR, but thought it would be useful to discuss the preferred way before doing so. There are a few options:

1. Move the imports into the functions that use them, like in the patch I made in pyodide. There are only two functions in astropy.utils.data that use ssl and only a single function in astropy.utils.console that uses concurrent.futures, so it’s a pretty simple fix. And when these functions are run on pyodide, the error is obvious. The disadvantage is that the imports then become more opaque, because they are no longer at the top of the file (but one could put a comment there pointing this out to avoid future confusion).
2. Feature test whether these libraries are available and only raise an error in the functions that use them if not. This keeps the top-of-file import, but means that a bit of code has to be included that only really applies to pyodide (because standard-library packages should always be available when using a regular Python distribution).
3. Detect whether one is running in pyodide and decide on behavior based on that (import sys; 'pyodide' in sys.modules detects pyodide). This would cleanly show why the imports are done in the way they are done, but requires special code for pyodide. Could also check whether the platform is platform.system() == 'Emscripten' to detect whether one is running in the browser more generally.

I think 1. is the easiest fix to make, but 2. is a decent alternative. I wouldn’t want to do 3., because it’s plausible that there would be non-pyodideor non-Emscripten-based Python distributions in the browser.

[jobovy]

Thanks for the comments all! Looks like there’s at least no strong objection to 1., so I will go ahead and implement that.

For the use of ssl in utils.py it actually looks like this function could be refactored so that if a ssl context can’t be built (because ssl isn’t importable) then it falls back to http. That might make it less likely to error?

Yes, maybe this is possible. But I don’t know whether there is much point to doing this for the purpose of running in pyodide. Any Python connection stuff is difficult to support in pyodide and the general recommendation is to just use javascript tools for making HTTP or HTTPS requests (so writing an astroquery version that runs in the browser would be complicated). So given that the ssl library should be available to anybody running astropy in regular Python, I don’t think it’s worth much special effort to cope with ssl not being available in the browser.

[Cadair]

(I am also generally pro option 1, but we can probably do more to make the code work if we wanted to)