Use data tables together with macros plugin

[sdellwig]

Hi I want to use the macros plugin to include a md file into another
{% include 'architecture/base/AR-REQ.md' %}
This md file contains a data table, read from csv {{ read_csv('AR-REQ.csv') }}

This combination does not work because the {{ }} syntax is already taken by the jinja2 extension from the macros plugin:
jinja2.exceptions.UndefinedError: 'read_csv' is undefined

Does someone know a solution for this?

[squidfunk]

Good question. Recommendation: ask the maintainers of the macros plugin ☺️

[sdellwig]

Sure, will do 😁 I just hoped for some experience. Since it is bundled in material, the chance is high that someone else ran into that.

[squidfunk]

The macros plugin is not bundled with Material for MkDocs.

[sdellwig]

You were obviously right 😅 sorry, my bad.

I'll post the answer here if I find a solution.

[timvink]

Are you using the table-reader plugin? (https://github.com/timvink/mkdocs-table-reader-plugin) ?

I am planning to build an alternative syntax for those tables, you can watch this issue: timvink/mkdocs-table-reader-plugin#45

[sdellwig]

Hi Tim, yes I'm using table-reader plugin. The alternative syntax would hopefully solve my problem 👍
This would be great 😁

[fralau]

Just in case, see also timvink/mkdocs-table-reader-plugin#57, where a proposal for a solution has been discussed in detail.

[FredZinelli]

Another solution is to change the syntax of the macro calls for the macros plugin, replacing {{ ... }} with something else:

https://mkdocs-macros-plugin.readthedocs.io/en/latest/rendering/#solution-5-altering-the-syntax-of-jinja2-for-mkdocs-macros

[timvink]

Hi @sdellwig , table-reader v3+ now supports mkdocs-macros-plugin. So your original example should now work

[sdellwig]

Great, I will try that 👍

[fralau]

@timvink This seems a beautifully elegant solution. Basically, if I read the code correctly, if the table-reader plugin finds the Mkdocs-Macros plugin, it inserts itself into the list of macros, variables and filters.

Interestingly, it should auto-document if you type the {{ macros_info() }} in a page.

[timvink]

Thanks! ❤️

[fralau]

Is there some order to follow, in the list of plugins (Mkdocs-Macros should be declared first, or it doesn't matter?)

[fralau]

Thinking of it 🤔.

mkdocs-macros does have a way to register additional filters, variables and macros, in the form of three attributes (lists).

• MacrosPlugin.macros
• MacrosPlugin.filters
• MacrosPlugin.variables

But that would work only if it is declared before the other plugin.

If we wanted to do the other way round, we should change the structure of the plugin a little. I purposefully made variables, macros and filters inaccessible if there was an attempt to access them before on_config. Now, we want a different behavior.

Not too difficult to do 🤔 . One possibility, would be to delegate the self-initialization to those three properties, so that they appear always available, even before on_config. The macros, filters and variables would then be registered before the others (with the risk of being overwritten if there is another macro with the same name).

Another possibility, which might be safer, would be to simply add three properties:

• last_macros
• last_filters
• last_variables

These would be read on top of the rest, and therefore guaranteed to work (in case of homonyms).

What would be your idea on the above?

[timvink]

Make a set of .register_*() methods where plugins can register additional stuff. If a reserved name is used (because macros already wants to use it), raise an error.

That way, the order of plugins shouldn't matters, as long as the registration is done during on_config (which you can enforce probably, by detecting the current event in the register method)

[fralau]

That could work...

.register_macros(), .register_filters() and .register_variables() 🤔

In that case, I would add those items last, and cause an error if the item already exists.

[timvink]

Sounds good 👍

[fralau]

For the implementation, see fralau/mkdocs-macros-plugin#237