`test_logging`'s test_111615 fails under WASI

[brettcannon]

Bug report

Bug description:

#111638 broke WASI builds due to assuming multiprocessing was always available.

Failure can be seen at https://buildbot.python.org/all/#/builders/1046/builds/3844 .

CPython versions tested on:

CPython main branch

Operating systems tested on:

No response

Linked PRs

• gh-113692: skip a test if multiprocessing isn't available. #113704
• [3.12] gh-113692: skip a test if multiprocessing isn't available. (GH-113704) #113844

[brettcannon]

/cc @vsajip

[vsajip]

Hmm, just catching an ImportError on import multiprocessing doesn't seem to fix it. What's the easiest way to see the exact failure message?

[brettcannon]

What's the easiest way to see the exact failure message?

https://buildbot.python.org/all/#/builders/1046/builds/3844/steps/11/logs/stdio , line 980.

This is how the multiprocessing tests handle if the module isn't built:

cpython/Lib/test/_test_multiprocessing.py

Lines 41 to 42 in 1ae7ceb

	# Skip tests if _multiprocessing wasn't built.
	_multiprocessing = import_helper.import_module('_multiprocessing')

[vsajip]

D'oh! Can't believe I missed that line, scrolled up and down too fast, I guess 🙈 So multiprocessing is built on WASI, but _multiprocessing isn't? I wonder what the logic there is.

[brettcannon]

D'oh! Can't believe I missed that line, scrolled up and down too fast, I guess 🙈 So multiprocessing is built on WASI, but _multiprocessing isn't?

Sort of. Since multiprocessing is a .py file it's more that it isn't stripped out.

I wonder what the logic there is.

I believe the original idea is enough code out there blindly assumes the module exists when importing globally, that even code that doesn't end up using the module would fail. There's also the possibility that the code just wants a constant or some code that does work (seen the former w/ ctypes).