Files
pallectrum/electrum/plugins
SomberNight 24980feab7 config: introduce ConfigVars
A new config API is introduced, and ~all of the codebase is adapted to it.
The old API is kept but mainly only for dynamic usage where its extra flexibility is needed.

Using examples, the old config API looked this:
```
>>> config.get("request_expiry", 86400)
604800
>>> config.set_key("request_expiry", 86400)
>>>
```

The new config API instead:
```
>>> config.WALLET_PAYREQ_EXPIRY_SECONDS
604800
>>> config.WALLET_PAYREQ_EXPIRY_SECONDS = 86400
>>>
```

The old API operated on arbitrary string keys, the new one uses
a static ~enum-like list of variables.

With the new API:
- there is a single centralised list of config variables, as opposed to
  these being scattered all over
- no more duplication of default values (in the getters)
- there is now some (minimal for now) type-validation/conversion for
  the config values

closes https://github.com/spesmilo/electrum/pull/5640
closes https://github.com/spesmilo/electrum/pull/5649

Note: there is yet a third API added here, for certain niche/abstract use-cases,
where we need a reference to the config variable itself.
It should only be used when needed:
```
>>> var = config.cv.WALLET_PAYREQ_EXPIRY_SECONDS
>>> var
<ConfigVarWithConfig key='request_expiry'>
>>> var.get()
604800
>>> var.set(3600)
>>> var.get_default_value()
86400
>>> var.is_set()
True
>>> var.is_modifiable()
True
```
2023-05-25 17:39:48 +00:00
..
2023-04-24 12:58:01 +00:00
2023-04-24 12:58:01 +00:00
2023-04-24 12:58:01 +00:00
2023-04-24 13:00:07 +00:00
2023-04-24 12:58:01 +00:00
2023-05-25 17:39:48 +00:00
2023-05-25 17:39:48 +00:00
2023-04-24 12:58:01 +00:00
2023-05-25 17:39:48 +00:00

Plugin rules:

 * The plugin system of Electrum is designed to allow the development
   of new features without increasing the core code of Electrum.

 * Electrum is written in pure python. if you want to add a feature
   that requires non-python libraries, then it must be submitted as a
   plugin. If the feature you want to add requires communication with
   a remote server (not an Electrum server), then it should be a
   plugin as well. If the feature you want to add introduces new
   dependencies in the code, then it should probably be a plugin.

 * We expect plugin developers to maintain their plugin code. However,
   once a plugin is merged in Electrum, we will have to maintain it
   too, because changes in the Electrum code often require updates in
   the plugin code. Therefore, plugins have to be easy to maintain. If
   we believe that a plugin will create too much maintenance work in
   the future, it will be rejected.

 * Plugins should be compatible with Electrum's conventions. If your
   plugin does not fit with Electrum's architecture, or if we believe
   that it will create too much maintenance work, it will not be
   accepted. In particular, do not duplicate existing Electrum code in
   your plugin.

 * We may decide to remove a plugin after it has been merged in
   Electrum. For this reason, a plugin must be easily removable,
   without putting at risk the user's bitcoins. If we feel that a
   plugin cannot be removed without threatening users who rely on it,
   we will not merge it.