**BUG FOUND**
The code in `Updater.check_appcast()` assumes that
`semantic_version.SimpleSpec.select()` will say "5.6.1 is an upgrade for
this 5.6.0". But it doesn't. It's looking for *matches*.
So this needs to be a proper loop/compare *and* should only take into account
options *for the current platform*.
This fixes an apparently harmless bug in the `openurl()` function defined
in this module (it's not part of the class).
1. On `win32` lookup the user setting for opening HTTPS URLs.
2. If that doesn't look like IE or Edge...
3. Set `cls` to the value for that.
4. Now look up the 'use this command' for *that* ...
5. And if it doesn't have `iexplore` in it...
6. Use `subprocess.Popen()` to invoke that browser with the given URL.
The problem is that step 6 still tries to use `buf.value`. But `buf` is
no longer present as it was from before 5989acd0d3
changed over to `winreg`. It should be just `value` from the winreg
calls.
That exception is then caught and ignored, and it ends up just running
`webbrowser.open(url)` anyway.
To be honest, this feels like we should just make this an unconditional
call to `webbrowser.open(url)` now, given apparently no-one's complained
about it always actually using that not working for them. Given Edge is
Chrome-based now, and any supported OS should have Edge, Chrome or Firefox
(OK, maybe Safari and some others) as the HTTPS browser, I don't see this
being an issue.
It turns out that you don't need to call `.configure(keyword=...)` on tk
widgets. You can just treat them as a dict with the available option as
a key.
This neatly gets rid of the type hint issues.
Conversion from %-format to f-string means an `assert ..., string`` is now
a condition and a `raise AssertionError(string)`. The problem being that
f-string gets evaluated before the assert, but in this case the things the
f-string relies on are only there if the assert triggers.
The output of this was confirmed the 'same' as from before this work:
1. Generate the output.
2. `cut -c 1-68` to a copy.
3. diff those files.
This is necessary so as to not have 'every' line be different due to the
timestamp on it.
* 'type: ignore' some ctypes operations on variables.
* Use `c_long(<value>)` on some returns. The ctypes types do work that way
as constructors.
* Fix the BAseHTTPHandler.log_request() types to match superclass.
* flake8 6.0.0 dropped support for, the broken, --diff.
* We want to only run against python files. We will have 'git diff's for
other types of files.
* Uses 'git diff -z', 'grep -z -Z' and 'xargs -0' so as to pass NUL-terminated
strings around to avoid "special characters in path/filenames" issues.
* Typed `master` to each `__init__()`.
* Having to `# type: ignore` the base class for the classes which are
"tk on darwin, else ttk" as this 'dynamic' type confuses mypy.
See the comment on `class Frame` for a suggested proper fix, which will
be more work.
* This did, however, remind me that the `data` passed into `cmdr_data()`
is an amalgam of `/profile`, `/market` and `/shipyard` queries.
This means that the data.source_endpoint is **not correct for all of
the data and its use**. As such I had to pass 'hard coded' values into
the function from the various CAPI export functions. They know what it
is they're exporting.
* As this reminded me that "CAPI `data` is actually a `CAPIDATA`", I've
documented that in PLUGINS.md, but with a dire warning against relying on
any of the extra properties.
* This is *temporary* pending properly implementing utilising the Legacy
CAPI host.
* Check in the EDMarketConnector.EDApp.capi_request_data() function *and*
also in some companion.session functions. But not absolutely all possible
entry points because we'll be undoing it when we implement Legacy support.
This *is* sufficient for the current core code entry points. If any plugin
is invoking its own CAPI requests, well it shouldn't be.
It's actually just the NAMES that got changed as part of the EDDN rework, so
this would have made no difference to the tests. But now a grep won't find
any instance of the old names.
Athanasius
Athanasius
dependabot[bot]