Fix: Disabling while in 'serve' mode after first run

[Sewer56]

This fixes a case where rebuilding the documentation when running in serve mode will ignore the enabled_on_serve.

When running exclude-unused-files in conjunction with mkdocs-material (9.5.25), I noticed that runs after the first run in serve mode were ignoring the enabled_on_serve flag. First run would be 1.3s, second would be 5.0 seconds.

After some log debugging, it turns out that self.config is actually reset between build runs in serve mode. And therefore setting self.config.enabled = False was not sticking.

To account for that, I stored an alternative variable disabled_by_serve that's tied to the self variable, outside of the config. This way, it should not be reset between runs.

---

Please Note: I've never really programmed in Python before, so debugging this has been a unique experience. 😅

[JonasDoesThings]

Hi, first of all; thanks for catching this bug and sorry for the review delay from my side! Great find :)

Second:
Maybe instead of introducing a second flag called self.disabled_by_serve we could just refactor and use one unified flag like self.is_enabled which we initially set to the config value self.config.enabled and then when checking for the self.config.enabled_on_serve instead of setting self.config.enabled = False like we did before (which is wrong), we could just set self.is_enabled to False.

I hope I didn't explain this too complicated 😅, but the gist is that maybe it's better to keep one final source of truth that decides if the plugin's functionality should be enabled instead of checking for multiple variables (if not self.config.enabled or self.disabled_by_serve) so that we don't forget to check for both variables when editing the code in the future and only have to check one source-of-truth variable.

What do you think about that? @Sewer56
You did really well even without being a Python dev :D
Greetings from Austria

[Sewer56]

That's a good idea actually, didn't think of unifying the value, would keep things simpler.

I'll get this sorted later today.

[Sewer56]

Oops, I forgot about this for a second somehow.
Anyway, the latest commit should get this sorted, pretty trivial patch.

[JonasDoesThings]

Hi, thanks for the addition @Sewer56
Looks good to me :)

I just quickly added a commit running the formatter (poetry run pre-commit run --all-files) to fix 2 whitespace issues in the PR.

I will release a new version including this change later today!
Greetings from Austria and I wish you a relaxing sunday

[Sewer56]

No worries.

And yeah, it does remind me, there's no decent universal ways to set things up like pre-commit hooks to automatically kick in locally. Every user has to manually init.

I do know it's possible to set up bots to format all incoming PRs provided user enables 'allow edits by maintainer' when submitting, but I've never looked into it much.

[JonasDoesThings]

Yeah, tbh I agree, pre-commit hooks are not that optimal
Running linting in CI Pipelines is probably still the best choice, but I also haven't looked into auto-formatting bots that add commits proactively yet