Q's about backwards compatibility for extensions where ckanext-theming is not installed

[duttonw]

Hi @smotornyuk ,

What is your solution for extensions to be able to use this ckanext-theming with ui but if the site admin does not install it to still use the 'legacy' templatable?

I.e. allowing uses to use the original or the new one.

Also:
I see you have made a portable (nice) version of bootstrap5 midnight. https://github.com/dataShades/ckanext-midnight-blue-theme

but you did not directly link to https://github.com/DataShades/ckanext-nswdesignsystem

Also tests are not working. I've been working on ensuring we have valid testing cicd pipeline prior to looking each of the extensions I manage.

master...duttonw:ckanext-theming:cicd

[smotornyuk]

Currently, I'm testing a mixin approach that enables minimal functionality for plugins that add ThemingMixin to their class hierarchy. It will look like this:

from ckanext.theming.plugin import ThemingMixin

class MyPlugin(ThemingMixin, p.SingletonPlugin):
    ...

When the theming plugin is not available, one of ThemingMixin's descendants will be used as the main entry point (the latest in the plugin list to preserve template inheritance order). It will register themes, provide ui variable in templates, etc.

When theming is enabled, ThemingMixin will behave as a no-op, and plugins won't be affected by it at all. Otherwise, if theming is not enabled and the theme is not configured, one of two polyfil themes will be chosen according to the portal's configuration. These themes are not intended for customization - they just reuse CKAN's core snippets and macros to provide all standard ui.* components. For example, ui.package component delegates rendering to snippets/package_item.html, and ui.input delegates rendering to CKAN's form.input macro.

In this way, extension can add dependency on theming with minimal version restriction: dependencies = ["ckanext-theming>=0.0.4"] and they will function with or without theming enabled.

There are two problems with this approach:

• Interface inheritance works with CKAN >= v2.11. It's not a big problem as CKAN's policy is to support the last two versions of CKAN(which will be 2.11 and 2.12 in few weeks). I'd like to make the solution compatible with older CKAN versions, but currently other things have higher priority.

• ThemingMixin itself implements ITheme, p.IConfigurer and p.IMiddleware. So it's critical that anyone who uses it and implements the same interfaces in their plugins call super() inside the corresponding methods. For example, when you need a middleware, want to update config, and register a theme inside a plugin that extends ThemingMixin, you'll have to do the following:

  class MyPlugin(ThemingMixin, p.SingletonPlugin):
    @override
    def update_config(self, config: Any):
        super().update_config(config)
        ...
  
    @override
    def register_themes(self) -> list[lib.Theme]:
        super().register_themes()
        ...
  
    @override
    def make_middleware(self, app: types.CKANApp, config: Any) -> types.CKANApp:
        super().make_middleware(app, config)
        ...
        return app

  Without these super() calls, the magic from ThemingMixin will disappear, and we will go back to the mandatory theming plugin being enabled.

I thought about using a simpler polyfill, but this solution is the most balanced in terms of simplicity and amount of available features.

---

Thanks for the notice about the NSW design system - it's hard to keep an eye on everything when you are working inside different repositories and also trying to integrate them into your projects at the same time.

---

I'll look into tests: probably it's worth keeping only unit tests of the core logic and omitting e2e tests of the frontend for now.

[duttonw]

may need a bit more than just

from ckanext.theming.plugin import ThemingMixin

since if the plugin is not even in the site this will crash, it may need a try / catch around it and for the 'extension' person to have a 'dummy' class that is needed to not have it flake.

As to your e2e testing needs, i've started to split 'unit testing' of core from themes, but with your extension having some themes inside it should still be tested in integration mode.

It should also help allow 'breakout' for individual theme modules based off the same cicd pipeline.

As you chose to use pytest for both unit and integration, I've gone down the route of using 'markings' for each type so they can be split at runtime.

[duttonw]

I also see @smotornyuk that there is a cyclic class dependency in this theme which makes things unhappy when doing fully qualified named

[duttonw]

Also I've gotten closer in getting your plugin to have a working unit + integration suite and you do have 'failing' tests on your built in themes.

So, have you been running this on latest dev or an old 2.12 branch since things have gone side ways :/

Also master does not use 3.11+ python and still on 3.10 :/

https://github.com/DataShades/ckanext-theming/compare/master...duttonw:ckanext-theming:cicd_v2?expand=1
https://github.com/duttonw/ckanext-theming/actions/runs/29062333439/job/86266665664

INTERNALERROR>   File "/__w/ckanext-theming/ckanext-theming/ckanext/theming/lib.py", line 55, in <module>
INTERNALERROR>     class Util(BaseUtil):
INTERNALERROR>   File "/__w/ckanext-theming/ckanext-theming/ckanext/theming/lib.py", line 230, in Util
INTERNALERROR>     def now(self, tz: datetime.timezone = datetime.UTC) -> datetime.datetime:
INTERNALERROR> AttributeError: module 'datetime' has no attribute 'UTC'