It turned out that the "fixes semantic_version 2.9.0" version of py2exe
then has an issue with infi.systray because I was still using
`setuptools==60.6.0`, as that's what was latest when I last did anything
to cause its installation in my venv.
So, list it explicitly on the latest version, which works with py2exe from
<https://github.com/py2exe/py2exe/actions/runs/1834917831>, and then
dependabot should prod us to keep it up to date.
For some reason this was complaining about file names being passed in by
pre-commit when `requirements-dev.txt` and `requirements.txt` were the two
changed files.
Explicitly passing them in `files:` config avoids this.
As such it doesn't have access to any extra modules you installed for your
program, or manually running `mypy <file>`.
So, leverage `additional_dependencies` to list anything that mypy ends
up complaining "that's not installed". Ref:
plugins\eddn.py:40: error: Library stubs not installed for "requests" (or incompatible with Python 3.10)
plugins\eddn.py:40: note: Hint: "python3 -m pip install types-requests"
plugins\eddn.py:40: note: (or run "mypy --install-types" to install all missing stub packages)
plugins\eddn.py:40: note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports
Found 1 error in 1 file (checked 1 source file)
CAPI only has the Cmdr wallet value (and loan if applicable), without anything
for 'total assets'. If we send Inara setCommanderCredits without
`commanderAssets` then Inara makes a bad judgement on it and sets an
incorrect total assets value.
Also:
> Do NOT set credits/assets unless you are absolutely sure they are correct. The journals currently doesn't contain crew wage cuts, so credit gains are very probably off for most of the players. Also, please, do not send each minor credits change, as it will spam player's credits log with unusable data and they won't be most likely very happy about it. It may be good to set credits just on the session start, session end and on the big changes or in hourly intervals.
So, let's just not.
* Call it system_name in `export_journal_fssdiscoveryscan()`, as `system`
could be amigbuous.
* Might as well use `system` passed in to `journal_entry()` when calling
`export_journal_approachsettlement()`.
1. We need StarPos (as well as StarSystem)
2. Adding more state tracking in this plugin is misguided.
3. So added it in monitor instead, putting *copies* of data in the
monitor.state dictionary.
4. So we reference those, but only available in journal_entry() itself, else
we'd need to pass the whole of `state` in.
5. So instead pass in the bits of `state` only when we need them.
Also, whilst the *current* code has the 'augment files' handled last in
then if/else tree we shouldn't assume that will always be the case.
So, be paranoid and use different variables for the augment-loaded entry
and its .lower event_name.
'cos you just know one of us will trip up on it later if there's ever some
'finally' code after that conditional tree.
Doing so from 'Rank' means the 'Progress' event hadn't happened yet, so of
course we only ever sent all zeroes for progress.
NB: Journal-v32 doc makes *no guarantee* about the order of the events.
Is it worth trying to be paranoid about that ? For a 100% new player
everything would be "all zeroes", so we would likely need to tweak things
to store `None` as default values, and check for such.
We want to *check* if there are any changes and only make a branch and add
commits if so. The upstream code has no option for this, so use it as
a starting point instead.
Specifically this is based on:
https://github.com/releasehub-com/github-action-create-pr-parent-submodule/blob/main/action.yml
aff9d0978a9bbcbc2961d621d5b108c4b46db5e7
* We need 'success' from the *step* to be when there ARE changes, and that
is in the special github output.
* In order for the whole job *not* to fail in the 'step check_for_changes
says it failed' case we need it to have `continue-on-error: true`.
Example only because I realised this probably won't preserve, e.g. the
checkout, python dependencies, winsparkle unpack etc, across jobs. Even if
the jobs are serialised by `needs`.
So expect this to get reverted next, it's only for reference.
If this doesn't work then it's time to try splitting all of this out
into separate jobs, rather than steps within a job, with dependencies to
ensure it works.
