Closes: #18535 - Skip incompatible plugins during startup

[bctiemann]

Closes: #18535

Changes the behavior of the PluginConfig.validate method so that if a plugin with incompatible min or max version specified, it raises an IncompatiblePluginError which is caught in settings.py and registering the plugin is skipped, allowing NetBox to launch cleanly with the plugin disabled.

[a084ed22]

Just to understand, this would print a warning at netbox upgrade time? The experience of figuring out which plugin has a strict max_version specified and breaks the upgrade process even on patch upgrades during the database migration step could really use to be more explanatory.

[bctiemann]

Yes, it would look like this:

Unable to load plugin netbox_branching: Plugin netbox_branching requires NetBox maximum version 4.2.1 (current: 4.2.2).
Watching for file changes with StatReloader
Performing system checks...

[jeremystretch]

We might want to rename the table columns. Currently, a plugin which fails to load shows false under "Installed" but confusingly still reports an installed version:

We should also highlight any plugins which failed to load to draw attention to them.

[bctiemann]

I renamed "Installed" to "Active", and I added a custom table column that allows an alert icon with a tooltip that explains the incompatibility issue:

[jeremystretch]

This renders an alert for every non-installed plugin. The value for is_installed should probably be None if the plugin has not been added to PLUGINS, and False if it has been added but failed to load.

[jeremystretch]

I'm not sure a custom column is needed here. Could we just use BooleanColumn and pass a custom HTML string for false_mark?

[bctiemann]

It doesn't look like it, if I want the false_mark text to be dynamically generated (i.e. to reflect the compatible version range). All the usage guidance I've been able to find suggests that the only way to add custom functionality referencing other columns is to subclass and override.

Also, in investigating this I found that BooleanColumn (and really all columns) ignore None values altogether and just render an — by default; if I comment out EMPTY_MARK it causes no ill effects. So setting is_installed to None means it doesn't trigger any custom column logic at all. I think for clarity I'll have to set another boolean field failed_to_load and reference that in the custom column logic, and set is_installed to True for all local plugins as it was before.

We might want to clean up BooleanColumn to remove the references to it, to avoid giving future devs the mistaken impression that we can incorporate None values into custom column logic.

[jeremystretch]

Could you just use a TemplateColumn then? I'd like to avoid introducing a new column class that only has one use case.

[bctiemann]

Good call, I think this will do the trick.

I fussed around a bunch trying to centralize the TRUE_MARK etc strings to avoid redundancy, but then realized we're already re-hard-coding those <i class="mdi mdi-check-bold"></i> in a million places so this only adds a little incremental chaos.

[jeremystretch]

I'm having a hard time discerning the difference between is_local and is_installed. It seems that any installed plugin has is_local set to True. Additionally, failed_to_load feels backward to me.

Could we simplify these to two attributes: is_enabled and is_installed (or is_loaded)? These would indicate whether the plugin is listed in settings.PLUGINS and whether is has been successfully loaded into the registry, respectively.

[bctiemann]

How about this -- is_local (which mirrors the local_plugins etc verbage, as opposed to catalog_plugins); and is_loaded, which indicates whether it's loaded into the registry. This removes is_installed as redundant, and the is_installed column remains on the table class but is purely rendered via the template logic.

[jeremystretch]

A plugin could fail to load for other reasons though, presumably. I'd avoid assuming it was due to a version incompatibility.

[bctiemann]

Rephrased the tooltip accordingly. It's possible to do an on-the-fly validation of the version range to see whether it should be suggested at all, but that got a bit too hairy.