funkybob / gilbert

A simple static site generator.
https://gilbert.readthedocs.io/en/latest/
MIT License
10 stars 4 forks source link

Loading order when registering a plugin when a default loader exists already #28

Closed shuttle1987 closed 5 years ago

shuttle1987 commented 5 years ago

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:

$ gilbert render
Searching /home/janis/digital_site/venv/lib/python3.7/site-packages/gilbert/plugins for plugins...
Loaded plugin: collection
Loaded plugin: scss
Loaded the Gilbert markdown with frontmatter loader
Loaded plugin: frontmatter_markdown
Loaded plugin: markdown
Loaded plugin: yaml
Loaded local plugins.
Found 16 content objects.

If I put a breakpoint in the loader function it doesn't get hit:

def load_frontmatter_md(path: Path):
    """Loader for markdown files that contain frontmatter"""
    data = path.read_text(encoding='utf-8')
    md = markdown.Markdown(extensions = ['meta'], output_format='html5')
    processed = md.convert(data)
    import pdb; pdb.set_trace() # this line is never hit
    return processed, md.Meta

Site.register_loader('md', load_frontmatter_md)
funkybob commented 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 :

  1. A config option to exclude plugins
  2. A config option to order plugins
  3. A default to importing plugins in lexicographic order.

Thoughts and opinions?

shuttle1987 commented 5 years ago

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

shuttle1987 commented 5 years ago

I could attempt to implement this and make a PR?

funkybob commented 5 years ago

Given some of them cause dependencies [like sass or markdown], I'd almost want them to be pushed out into separate packages, really.

shuttle1987 commented 5 years ago

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?

funkybob commented 5 years ago

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.

shuttle1987 commented 5 years ago

Alysha has started on the sass plugin here: https://github.com/Alysha-94/gilbert-scss

funkybob commented 5 years ago

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:

  1. Add creating a basic config.yml to the create command
  2. Look for the list of plugin modules in config.yml
  3. Honor the order of plugins from the config.

The loading of the config.yml came well after the plugin system was implemented, hence this not being the "obvious" solution from the start.

funkybob commented 5 years ago

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.