Plugins.stop was never called, so the Plugins thread only stopped
because of the is_running() check in run(), which triggers too late:
the Plugins thread was stopping after the main thread stopped.
E.g. playing around in the qt wizard with wallet creation for a Trezor,
and closing the wizard (only window):
``` 24.85 | E | p/plugin.Plugins |
Traceback (most recent call last):
File "/home/user/wspace/electrum/electrum/util.py", line 386, in run_jobs
job.run()
File "/home/user/wspace/electrum/electrum/plugin.py", line 430, in run
client.timeout(cutoff)
File "/home/user/wspace/electrum/electrum/plugin.py", line 363, in wrapper
return run_in_hwd_thread(partial(func, *args, **kwargs))
File "/home/user/wspace/electrum/electrum/plugin.py", line 355, in run_in_hwd_thread
fut = _hwd_comms_executor.submit(func)
File "/usr/lib/python3.10/concurrent/futures/thread.py", line 167, in submit
raise RuntimeError('cannot schedule new futures after shutdown')
RuntimeError: cannot schedule new futures after shutdown
```
if qt is not installed, e.g. on a server, was getting:
```
$ ./run_electrum sadasdasddsa
Traceback (most recent call last):
File "/home/user/wspace/electrum/./run_electrum", line 532, in <module>
main()
File "/home/user/wspace/electrum/./run_electrum", line 383, in main
lang = get_default_language(gui_name=gui_name)
File "/home/user/wspace/electrum/electrum/gui/default_lang.py", line 23, in get_default_language
from PyQt5.QtCore import QLocale
ModuleNotFoundError: No module named 'PyQt5.QtCore'
```
Without this,
`$ python3 -m unittest electrum.tests.regtest.TestUnixSockets.test_unixsockets`
was failing on my machine but succeeding on CI, due to timing differences.
I have reconsidered and now think that we should always hard-fail
if asserts asserts are disabled. It is just easier to reason about
the code knowing that asserts are evaluated.
If an end-user or library user has a concrete use case where this is
a problem, please open an issue and let us know.
follow-up
0f541be6f10e5464ca13
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
```
Note that 0f541be6f1 added a warning log if asserts are disabled.
It is intentional that these two things are in separate files:
We always want to log that warning, even if someone is using electrum as a library.
However, in that latter case, I think it's fine not to sys.exit(), but leave the decision up to the library user.
Similar thinking when running from source: let's log the warning but don't sys.exit().
The qt, qml, and kivy GUIs have a first-start network-setup screen
that allows the user customising the network settings before creating a wallet.
Previously the daemon used to create the network and start it, before this screen,
before the GUI even starts. If the user changed network settings, those would
be set on the already running network, potentially including restarting the network.
Now it becomes the responsibility of the GUI to start the network, allowing this
first-start customisation to take place before starting the network at all.
The qt and the qml GUIs are adapted to make use of this. Kivy, and the other
prototype GUIs are not adapted and just start the network right away, as before.
Related to prev commit: multiple (compatible) keystores can now match
with the same HardwareClientBase, so we might as well also allow
reusing existing Clients for the wizard.
If enabled, we log to stderr, which can get inspected via logcat.
Not user-friendly at all - but previously there was no way to get logs from a release build.
closes https://github.com/spesmilo/electrum/issues/7409
Just uncomment line 53 in make_apk, and you get a testnet apk that can co-exist with your mainnet install.
No need to do a clean rebuild of ".buildozer/" either.
When running a command, file logging is disabled as every
command-invocation would create a new logfile. However if the user
explicitly sets "-v" on the commandline, there's no reason why that
shouldn't work.
closes https://github.com/spesmilo/electrum/issues/4072
(this fix AFAICT only works on Windows, and #4072 contains some macOS reports as well,
however all recent reports are for Windows and overall most reports are for Windows,
so let's close it optimistically for now)
The old and new behaviour is as follows:
1. "pyinstaller" case: portable `.exe`, other `.exe`s with `--portable`, and `.dmg` with `--portable`
- uses `$PWD`
- note that when you double-click the portable `.exe` on Windows, `$PWD` is set to the parent folder, i.e. the datadir gets put next to the `.exe`
2. appimage `--portable`
- was broken (see https://github.com/spesmilo/electrum/issues/5551)
- (CHANGED NOW to) uses `$PWD`
3. git clone
- next to `run_electrum`
4. unpacking `tar.gz` and running locally from it
- next to `run_electrum`
5. `pip install *.tar.gz`, and calling "electrum --portable" from terminal
- used python's user script directory
- `~/.local/bin/electrum_data`
- `$VIRTUAL_ENV/bin/electrum_data`
- (CHANGED NOW to) uses `$PWD`
That is, we now almost always put the datadir in `$PWD`,
except for the local source case, where we put it next to `run_electrum`.
The "appimage" case (2) is now fixed.
The only breaking change is re case 5 which previously behaved completely
unintuitively and most likely not in a useful way.
closes https://github.com/spesmilo/electrum/issues/7732
fixes https://github.com/spesmilo/electrum/issues/5551
pyinstaller 4.3 changed the value of `__file__`.
This change makes our behaviour independent of that pyinstaller change
(we always behave like old versions of pyinstaller).
fixes https://github.com/spesmilo/electrum/issues/7729
regression was introduced by b5951adc29
- rename `is_bundle` to `is_pyinstaller` (no semantic changes, just to clearer name)
- define `is_appimage`
- add comment to explain `is_local`
- its value is the same as before (but more explicit definition)
- define `is_git_clone`, and restrict DeprecationWarnings to that case
aiorpcx 0.20 changed the behaviour/API of TaskGroups.
When used as a context manager, TaskGroups no longer propagate
exceptions raised by their tasks. Instead, the calling code has
to explicitly check the results of tasks and decide whether to re-raise
any exceptions.
This is a significant change, and so this commit introduces "OldTaskGroup",
which should behave as the TaskGroup class of old aiorpcx. All existing
usages of TaskGroup are replaced with OldTaskGroup.
closes https://github.com/spesmilo/electrum/issues/7446
* Remove check for sign with privkey in init_cmdline
* Add with_privkey and with_wallet variants of signtransaction command
* Add unit tests for signtransaction_with_privkey and signtransaction_with_wallet commands
Previously, during early-startup (until configure_logging(config) is
called in run_electrum),
- the stderr log handler lost all log messages below warning level, and
- the file log handler lost all log messages regardless of log level
We now instead start buffering log messages in memory as soon as
electrum.logging is imported. The buffer is dumped into the
stderr and file log handlers when they are fully set up, and then
the buffer is discarded (and the temporary log handler is removed).
Note that messages are not logged until configure_logging() is called.
Previously WARNING/ERROR messages would get logged immediately to stderr,
but not anymore. This was changed so that the order of the log messages
can be kept intact. (if we log WARNINGs immediately, but need to delay
INFOs until the config is available, messages would either be out of order
or alternatively there would be duplicates)
Relatedly, we now follow the recommendation of the python docs re
logging for libraries [0]: we try to only configure logging if running via
run_electrum (the main script) and not when e.g. a 3rd party script
imports electrum.
[0]: https://docs.python.org/3/howto/logging.html#configuring-logging-for-a-library
Note that newer aiorpcx started requiring python 3.8, so we cannot use
the latest versions, until we too bump the min python version to 3.8.
We should not do that until debian stable ships python 3.8.
Also, new aiorpcx introduced some API changes which we will need to
adopt, so even if the user locally has recent enough python, we need
old aiorpcx atm.
related: https://github.com/spesmilo/electrum/issues/7118
When the app is started, the password is checked against all
wallets in the directory.
If the test passes:
- subsequent wallet creations will use the same password
- subsequent password updates will be performed on all wallets
- wallets that are not storage encrypted will encrypted
on the next password update (even if they are watching-only)
This behaviour is restricted on Android, with a 'single_password' config variable.
Wallet creation without password is disabled if single_password is set
When running kivy on Linux desktop,
running from git clone, `./run_electrum -g kivy` worked,
but `pip install -e .; electrum -g kivy` did not.
This was due to the relative paths using cwd as base.
see #6835
