If the venv creation fails, should we consider launching Mu with reduced functionality?

[carlosperate]

Over time we are likely to hit issues like these again, which can happen either when creating a venv or on the first Mu launch, of version of Mu that were working "fine" in the past. This might be specially true for users of old versions of Mu, which is most likely people stuck in old OS versions unable to update:

• venv: Add Flask subdependency upper bound limit. #2058
• Update venv Flash version to fix issue with incompatible dependency. #2051
• Depend on ipython_genutils to fix issue with missing ipykernel dependency #1844
• Remove qtconsole from user venv and permanently leave ipykernel. #1692
• Set ipykernel version to be < 6.0 for macOS 10.13 compatibility #1686
• Remove adafruit_board_toolkit from user venv and lock major version of PySerial in setup.py #1491

I think we need come up with a way to deal with venv failures that doesn't completely crash Mu, specially since we have a significant portion of users that use Mu for micro:bit, CircuitPython, and other modes that don't require the venv.

What options do we have if the venv creation fails?

• Launch without Python and similar modes, or maybe show an error message only when any of those modes are selected?
• Drop the venv and use the Mu Python environment?
  • Even if that means the user could accidentally break Mu's dependencies, this is no worse than the current situation, which is Mu not launching.
• Or maybe we should pin all venv dependencies to a single version? Like of like a requirements.txt file.
  • This sounds like it might be the simplest solution, but we also need to figure out the differences in dependencies for each OS, platform, and Python version, so we could easily end up with 12 to 20 lists requirements.txt files (or a single file with a lot of rules).
• Something else?