ENH: Improve API of set_config

[larsoner]

I just wanted to enable CUDA on my machine, and had to do mne.get_config to get the config keys to figure out what to set, which was a bit annoying. That is because set_config has the api:

set_config(key: str, value: str | None, home_dir: str | None = None, set_env: bool = True)

So you have to know the key we use in the config file, which is really more of an implementation detail (though it does allow use via env vars, too, which is nice), i.e., I had to do:

mne.set_config("MNE_USE_CUDA", "true")

What would have been a lot nicer would have been:

mne.set_config(use_cuda=True)

So I have the following API improvement proposal:

set_config(
    key: str | None,              # add =None default
    value: str | None,
    home_dir: str | None = None,
    set_env: bool = True,
    *,  # ↓↓↓ new! ↓↓↓
    use_cuda="-preserve-",
    subjects_dir="-preserve-",
    ...
):
"""
Set a MNE-Python preference key in the config file and environment.

When setting values using keyword-only parameters (anything after the ``*``
in the signature):

- The special string value ``"-preserve-"`` means "do not change the existing
  value (if present) unless it's changed using ``key`` and ``value`` above".
- Any keyword-only parameter set to ``None`` will be removed from the config file.

Parameters
-----------
...
use_cuda : bool | str | None
    Controls CUDA availability using a bool (including string-like equivalents,
    e.g., ``"false"``). Corresponds to the ``MNE_USE_CUDA`` environment
    variable.
...
"""

Thoughts?

@mscheltienne somewhere in the back of my mind I think you brought up something similar recently but after a search I couldn't find anything.

[drammock]

I'm on board with the motivation for this change, it's not a quick-and-easy API for a task that should be quick-and-easy.

But, having both old and new APIs in one function feels inelegant. Did you consider making set_config legacy, and creating a new interface ("update_config" maybe?) for the new way of doing things?

Another thought: if in the current API the type hint for key were a list of literal (valid) keys instead of just str then maybe tab completion gets enough better that the bigger API change is no longer urgent? Everything's still going to be all-caps, and almost everything's still going to start with MNE_, so those little annoyances won't go away, but maybe it's enough?

[larsoner]

Did you consider making set_config legacy, and creating a new interface ("update_config" maybe?) for the new way of doing things?

No, an update_config would be okay as well I suppose. Maybe that's the easiest way to go. It's not symmetric with get_config but that one we probably won't change, so that seems okay.

Another thought: if in the current API the type hint for key were a list of literal (valid) keys instead of just str then maybe tab completion gets enough better that the bigger API change is no longer urgent? Everything's still going to be all-caps, and almost everything's still going to start with MNE_, so those little annoyances won't go away, but maybe it's enough?

I don't think it solves the problems as well. My hope is to design an interface that is as clean/pythonic from the user end as possible. In this sense set_config(use_cuda=True) or update_config(use_cuda=True) is better/more pythonic than set_config("MNE_USE_CUDA", "true") even if we improve discoverability of the key options through Literal type hints or similar. (And I'd also expect it to be a very long type hint, so maybe not render as nicely as a Parameter list, and numpydoc wouldn't render it super nicely if at all, etc. so we'd have to duplicate it a bit I think.)