When I stopped running the version check before the tests I also stopped initializing Version, which can be used in tests to watch out for font changes across versions. As a result I started seeing a test failure with LÖVE v12.
It looks like all manual tests pass now. And we're also printing the warning about version checks before running tests, which can come in handy if a new version ever causes test failures. The only thing that makes me unhappy is the fact that we're calling the version check twice. And oh, the fact that this part around initialization and version management is clearly still immature.
I'll capture some desires and fragmentary thought processes around them:
If there's an error, go to the source editor.
But oh, don't go to source editor on some unactionable errors, so we
include a new Current_app
mode for them:
[Source editor can be confusing for errors. Also an editor! But not showing the file you asked for!]
But our framework clears the warning after running tests:
[Perhaps Current_app
is the wrong place for this third hacky mode,
since we actually want to continue running. Perhaps it's orthogonal to
Current_app
.]
[Ideally I wouldn't run the tests after the version check. I'd pause, wait for a key and then resume tests? "Muddle through" is a pain to orchestrate.]
We store Current_app
in settings. But we don't really intend to
persist a Current_app
of 'error'. Only the main app or 'source'
editor.
[Another vote against storing 'error' in Current_app
.]
So we need to rerun the version check after running tests to actually show the warning.
[Perhaps I need to separate out the side-effect of setting Version
from the side-effect of changing Current_app
. But that's not right
either, because I do still want to raise an error message if the
version check fails before running tests. Which brings us back to
wanting to run the tests after raising the version check..]
One good thing: none of the bugs so far have been about silently ignoring test failures. I thought that might be the case for a bit, which was unnerving.
I grew similar muddiness in Mu's bootstrap system over time, with several surrounding modes around the core program that interacted poorly or at least unsatisfyingly with each other. On one level it just feels like this outer layer reflects muddy constraints in the real world. But perhaps there's some skill I still need to learn here..
Why am I even displaying this error if we're going to try to muddle through anyway? In (vain) hopes that someone will send me that information. It's not terribly actionable even to me. But it's really intended for when making changes. If a test fails then, you want to know.
The code would be cleaner if I just threw an unrecoverable error from the version check. Historically, the way I arrived at this solution was:
Perhaps I should stop caching Version and just recompute it each time. It's only used once so far, hardly seems worth the global.
We have two bits of irreducible complexity here:
O5F6DNPGQPJII6CCUYRKW6DMF3OI22YSUNBFH5PC4HLZIM3YGYBQC