pip list --outdated fails on platforms without sem_open

[landfillbaby]

Environment

• pip version: 20.1
• Python version: 3.8.2
• OS: Android Termux

Description
running pip list -o leads to an ImportError in multiprocessing.dummy:
"ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770.”

not bothering with traceback, since it's easily traced to the use of multiprocessing.dummy.Pool in commands/list.py line 216.

[deveshks]

The issue in the above log is https://bugs.python.org/issue3770

[uranusjr]

This import was introduced as a part of #7964. We probably should disable parallellisation when this happens. cc @CrafterKolyan

[deveshks]

Can we try and fix it the way Cpython detects it ?

https://github.com/python/cpython/blob/d9a43e20facdf4ad10186f820601c6580e1baa80/Lib/multiprocessing/synchronize.py#L24-L33

[pfmoore]

See the last comment on that bug report, it's been closed for over 10 years. If this is a Python issue, it would need to be raised as a new bug.

Following the Python docs, multiprocessing.dummy is a wrapper around threading which is always available in Python 3.7+ So it looks like the OP's version of Python is incomplete?

However, this does bring up the point that in Python older than 3.7, threading is an optional module, so pip should probably fall back to the old code when threading isn't available. In which case, we don't care about why multiprocessing.dummy doesn't work, and the OP's issue gets solved as well.

Can we try and fix it the way Cpython detects it ?

I'd just say that if the multiprocessing.dummy import fails, we should fall back to the single-threaded code.

[pradyunsg]

TBH, at this point, I feel like we should revert the original PR until we figure out the finer details of what we want parallelized code in pip to look like, what strategy we use to support platforms that don't have threading etc.

Originally posted by @pradyunsg in #8162 (comment)