Closed shuttle1987 closed 5 years ago
This is a tough one, and almost makes me regret making all the builtins act just like all the other plugins.
A few ideas spring to mind :
Thoughts and opinions?
I think it would be good to load all the builtins first so then any plugins will then overwrite the builtins if they get imported
I could attempt to implement this and make a PR?
Given some of them cause dependencies [like sass or markdown], I'd almost want them to be pushed out into separate packages, really.
Given some of them cause dependencies [like sass or markdown], I'd almost want them to be pushed out into separate packages, really.
Do you want to make them into plugin packages like the one I was putting together for the frontmatter enabled markdown?
Yeah, that's what I was thinking, but it would also be handy to be able to, for instance, "pip install gilbert[markdown, sass]".
Once the plugin packages exist that's a matter of adding extras_require to the setup.
Alysha has started on the sass plugin here: https://github.com/Alysha-94/gilbert-scss
After the recent efforts on using namespace plugins exposed some faulty assumptions on my part, I'm thinking of taking a different approach.
Embracing the Zen of Python, ISTM a better option would be to push the list of plugins into the config.yml
So:
The loading of the config.yml came well after the plugin system was implemented, hence this not being the "obvious" solution from the start.
I've just created a PR that will switch to an explicit plugin list configured in config.yml. Please review and let me know what you think.
I've been doing some work on the Markdown frontmatter plugin here: https://github.com/shuttle1987/gilbert-frontmatter-markdown
Currently it appears that it gets loaded but then the default markdown loader gets loaded afterwards and hence the plugin doesn't get a chance to process files:
If I put a breakpoint in the loader function it doesn't get hit: