Release pelican-liquid-tags v1.0.0 on PyPI about liquid-tags HOT 7 CLOSED

Many thanks, @mirekdlugosz and @kdeldycke. I pushed a few follow-up changes but still need to give the README a once-over before anointing the new release. Will update here when that's all done. ✅

from liquid-tags.

Liquid Tags v1.0.0 has been published and is now available on PyPI. Many thanks to @mirekdlugosz and @kdeldycke for helping make that possible! 🎉

from liquid-tags.

Thanks @mirekdlugosz for your great work!

I'm re-opening the issue: if the main branch is now is good state for 1.0.0, we still need @justinmayer to setup the GitHub actions workflow and push a 1.0.0 build of liquid-tags on PyPi.

from liquid-tags.

This issue was particularly exciting to watch closely over the last week, not gonna lie! Thanks to everyone involved :)

from liquid-tags.

@kdeldycke @justinmayer
I wanted to discuss one problem with you.
liquid_tags contain both framework for registering tags, and library of tags. Historically, you had to define specific tags as plugins in your pelicanconf: PLUGINS = ['liquid_tags.include_code'].

I managed to bring plugin to somewhat decent shape, where all tests pass, linter doesn't complain, package can be installed and is recognized by pelican-plugins. The problem is, right now it only registers framework. So while plugin is available, it won't recognize any tags in posts.

I can think of 3 solutions, and I wanted to get your opinion on how we should proceed. Of course other ideas are welcome, too.

1. Expose all tags in plugin __init__.py

This way, installing plugin will enable all tags. This is potentially backwards-incompatible - if you wrote {% spotify %} in post without including liquid_tags.spotify, liquid tags would leave it as is. Now it would translate this string to spotify block.

As far as I can tell, tags that require additional modules (like pygalcharts) tend to import them when tag is processed, so people who aren't using these special tags will not need to install additional packages in their website venv.

This solution will also require refactoring of all the tests, as from . import audio will return audio function instead of audio.py module.

2. Teach pelican to look for namespaced plugins modules when processing PLUGINS setting

pelican/plugins/_utils.py::load_legacy_plugin will try to import package, but does not consider that dotted plugin name may refer to module inside namespaced plugin. I have PoC patch that changes that.

The main benefit is that namespaced plugin will continue to work with legacy settings. In fact, it will require legacy setting to be present. The main problem is that we will need to hold plugin release until pelican version with patch is released.

3. Introduce new setting to specify which tags to load

During registration, plugin can look into some new setting variable, and automatically import tags specified there. I had initial success with something like LIQUID_TAGS = ['img', 'youtube', 'video']. Main drawback is that we force users to update their settings when switching to namespaced plugin, but we kind of encourage it right now anyway.

from liquid-tags.

Sorry @mirekdlugosz for the delayed answer!

I'm not (yet) a user of that plugin so I'm not in the best position to provide feedback on the different proposals.

Here are some comments on each point:

1. I did not realized some plugins requires extra dependencies like. I guess you can add these in the pyproject.toml file, with their own section. See:

   • liquid-tags/pyproject.toml

     Lines 51 to 52 in 8765ad7

     	[tool.poetry.extras]
     	markdown = ["markdown"]

   • https://python-poetry.org/docs/pyproject/#extras
   • https://www.python.org/dev/peps/pep-0621/#dependencies-optional-dependencies

2. That can be more or less emulated by the plugin itself. At initialization, you can peek into Pelican contextual configuration and hack your way into the PLUGINS settings I guess. That what I'm currently doing in my Plumage theme to setup third party plugins I depends on. See: https://github.com/kdeldycke/plumage/blob/d8f16000a2cbfc8f758903d8e8b4d7df6788cc5e/plumage/__init__.py#L171 . But this might be a little bit too fragile.

3. This seems like a reasonable solution. It makes tag activation explicit and simple. And you already started working in that direction. With the re-packaging of the plugin and the upcoming v1.0.0 release, feel free to introduce new options or new behaviour. It is OK to introduce some breaking changes to pave out the future of the plugin.

from liquid-tags.

@kdeldycke I was leaning towards solution number 3, and this is what I ended up implementing. I feel this is safest option, as doesn't require everyone to install all dependencies of all tags.

I have now raised PR with all my work, #6

from liquid-tags.