You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As maintainer, I would like to deprecate the built-in template engines, so I can spend more of my efforts on the core capabilities of Rex.
Describe the solution you'd like
Rex::Template was the original templating engine, but its approach had problems, like almost useless diagnostics. So Rex::Template::NG was born to address some of the shortcomings, but its results are still not fully compatible yet, so we never truly made the switch (default engine has changed, but the old one is still around "just in case").
This situation provides some false promises to users, and adds considerable overhead for both users and maintainers. Therefore I'd like to help avoiding the whole rabbit hole in the first place.
I believe templating is complex topic on its own, and it's best to offload the responsibility to external modules, of which there are dozens on CPAN already. That way we could focus more on the core capabilities of Rex, while everyone may pick their preferred templating engine for their needs.
I think we could put up a one-time warning on the first use of any of the built-in engines in a given run, so later when the time comes, get rid of the modules themselves. It would also help raising awareness about the potential problems when using the built-in ones.
Describe alternatives you've considered
Creating our own "best" templating engine, at least in the limited scope of configuration management. It doesn't sound realistic to me.
EDIT: we can try and see if there's a good candidate on CPAN (with lightweight dependencies, compatible syntax, etc.) which we could use as a templating backend by default instead of inventing our own.
Additional context
The text was updated successfully, but these errors were encountered:
One idea is to use Text::Template::Simple to do the heavy lifting by default instead of our own custom solution(s).
It seems lightweight enough with a compatible syntax. Ideally if there are any diffs in the rendered output compared to the current core modules, all those would classify as bugfix and/or new features. In that case we might be able to plan a gradual shift towards using it.
User story
As maintainer,
I would like to deprecate the built-in template engines,
so I can spend more of my efforts on the core capabilities of Rex.
Describe the solution you'd like
Rex::Template was the original templating engine, but its approach had problems, like almost useless diagnostics. So Rex::Template::NG was born to address some of the shortcomings, but its results are still not fully compatible yet, so we never truly made the switch (default engine has changed, but the old one is still around "just in case").
This situation provides some false promises to users, and adds considerable overhead for both users and maintainers. Therefore I'd like to help avoiding the whole rabbit hole in the first place.
I believe templating is complex topic on its own, and it's best to offload the responsibility to external modules, of which there are dozens on CPAN already. That way we could focus more on the core capabilities of Rex, while everyone may pick their preferred templating engine for their needs.
I think we could put up a one-time warning on the first use of any of the built-in engines in a given run, so later when the time comes, get rid of the modules themselves. It would also help raising awareness about the potential problems when using the built-in ones.
Describe alternatives you've considered
Creating our own "best" templating engine, at least in the limited scope of configuration management. It doesn't sound realistic to me.
EDIT: we can try and see if there's a good candidate on CPAN (with lightweight dependencies, compatible syntax, etc.) which we could use as a templating backend by default instead of inventing our own.
Additional contextThe text was updated successfully, but these errors were encountered: