Clarify versioning blueprints in plugins #169
Conversation
…prints, show the blueprint versions in the UI footer
| f"{p_name} ({'v' + [v for v in p_bp_dict.values()][0] if len(p_bp_dict) == 1 else ', '.join(bp_name + ' v' + bp_version for bp_name, bp_version in p_bp_dict.items())})" | ||
| for p_name, p_bp_dict in current_app.config.get("LOADED_PLUGINS", {}).items() |
There was a problem hiding this comment.
I can clean this up with a util function, but I first wanted to get your opinion on plugin/blueprint versioning, @nhoening.
|
I can accept that a plugin author might want to organise their code using multiple blueprints, but my first reaction to this PR is that one version should suffice per plugin. We don't have multiple versions in FlexMeasures, either. |
|
So perhaps we shouldn't define the plugin version based on the (first) blueprint version? Is there a good alternative for where/how to specify the plugin version? Otherwise, we could revert to mandating only a single blueprint per plugin (i.e. partially revert #164). |
|
Maybe the |
|
(I'm not 100% sure why I placed it on the blueprint, but maybe I simply thought there'll be just one which defines the whole plugin so it's a fitting place). (Btw, I also believe my idea was that having only one blueprint with strict naming tied to the plugin could avoid possible naming conflicts with other blueprints from within FM or other plugins ― can that happen to us now?) |
|
I also believe this can merge into main, as it isn't connected to what the views-by-accounts branch is doing. |
Moved to #171 |
Make it clear that plugins version blueprints, and, in case there are multiple blueprints, show the blueprint versions in the UI footer.
In case of a plugin with a single blueprint, it shows up as
<plugin name> (v<blueprint_version>))(the blueprint version is reported as the plugin version, which was the behaviour we had before):In case of a plugin with multiple blueprints, it shows up as
<plugin name> (<blueprint_name> v<blueprint_version>)):