RFC: developer meta-environments

This week I needed to recreate my dev env. As you may know, I develop/contribute to several related packages, so I often want/need editable installs of many things and to have all the optional dependencies installed (so I can run their tests, build their docs, etc). This makes things... hard. For example:

• MNE-NIRS isn't really installable: its dependency sphinx_rtd_theme requires docutils<0.21 and its other (nested) dependency readme-renderer requires docutils>=0.21.2
• MNE-LSL forces installation of PyQt5, which can cause headaches if you choose/prefer to install MNE-Python with PyQt6 or PySide
• MNE-Connectivity pins pytest<8 and pydata_sphinx_theme==0.14.1 (specially bad problem for me as I also develop that theme, but others may also want to do local MNE doc builds against current main of that theme)

Possible solutions (please suggest others!)

1. migrate currently maintained MNE tools into a monorepo with a unified environment spec / lockfile (this is possible with e.g. Rye; see https://rdrn.me/postmodern-python/#monorepo)
2. unify a few key things to reduce pain:
   • use the same Qt binding across mne-python, mne-lsl, and mne-qt-browser
   • use the same sphinx theme (and version) across mne-nirs (rtd), mne-lsl (furo), mne-conectivity (pydata==0.14.1) and mne-python (pydata). Ideally we'd also use it for mne-bids-pipeline but I don't expect to win that argument.
3. Do nothing, and make devs use different envs for different packages they work on (I do this too... but it feels weird to need different envs just for working on different MNE packages...)

thoughts?

Start by reviewing the dependency conflicts described for MNE-NIRS, MNE-LSL, and MNE-Connectivity, then compare the three proposed environment strategies, including the Rye monorepo example. Done means the project has an agreed direction for handling development environments and a documented scope for any follow-up work.