Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Why config of "template_dir" is just a single directory #746

Open
TomFreudenberg opened this issue Feb 16, 2025 · 7 comments
Open
Assignees
Milestone

Comments

@TomFreudenberg
Copy link
Contributor

Hey @derks

in config there is the option:

### Where external templates are loaded from
template_dir: /var/lib/tokeo/templates/

but why not allowed multiple dirs or

### Where external templates are loaded from
template_dirs:
  - /var/lib/tokeo/templates/
  - /var/lib/custom/templates/
  - /xyz/templates/

If you like, I can creata a PR, currently I created my own extensions but for this I miss the reason why not by framework.

Cheers
Tom

@derks
Copy link
Member

derks commented Feb 17, 2025

@TomFreudenberg this I believe was an evolution in design. I think originally we only had template_dir, and then the list of template_dirs was introduced later. Per the docs, the App.Meta.template_dir is prepended to the list of App.Meta.template_dirs and takes precedence in the loading order:

https://cement.readthedocs.io/en/3.0/api/core/foundation.html#cement.core.foundation.App.Meta.template_dir

template_dir: Optional[str] = None
        """
        A directory path where template files can be loaded from.  By default,
        this setting is also overridden by the
        ``myapp.template_dir`` config setting parsed in any of the
        application configuration files .

        If set, this item will be **prepended** to
        ``App.Meta.template_dirs`` (giving it precedence over other
        ``template_dirs``.
        """

The list of App.Meta.template_dirs is processed prior to any TemplateHandler execution to load the template.

@TomFreudenberg
Copy link
Contributor Author

TomFreudenberg commented Feb 17, 2025

Hi @derks

I can agree but the question is if this must be the same in future.

For me, it would be great if

  1. template_dir

allows to be set by external config with "single string" or (new) "list of strings"

  1. template_dirs (preferred by me)

are available in external config as well

Currently neither will work.

What solution (1 or 2) would meet your needs the best?

@derks
Copy link
Member

derks commented Feb 19, 2025

@TomFreudenberg I agree, I think it would make sense to add to config. This is supported though with minor modifications.
There are two settings that determine this:

IMPORTANT NOTE: I believe that this will only work if using the YamlConfigHandler or JsonConfigHandler, as they support more complex data types. The following example is using the YamlConfigHandler (default with cement generate project):

~/.myapp.yml:

myapp:
    template_dir: /path/to/my/template-dir
    template_dirs:
    - /path/to/template/dir1
    - /path/to/template/dir2
    - /path/to/template/dir3

main.py:

class MyApp(App)
    class Meta:
        meta_override = ['template_dirs']

You can see it is honored:

app.run()
print(app._meta.template_dirs)

Output:

['/root/.myapp/templates', '/root/.config/myapp/templates', '/path/to/my/template-dir', '/path/to/template/dir3', '/path/to/template/dir2', '/path/to/template/dir1', '/usr/lib/myapp/templates']

@derks
Copy link
Member

derks commented Feb 19, 2025

@TomFreudenberg to further expand on your "ideal" request:

Setting a simple string with result in the string being expanded (as-is today). It would be a minor change to automatically convert a string to a list, but would need be implemented.

We do not have the same thing for "config_dir" vs "config_dirs", so I agree it is confusing to support both. I am in favor of deprecating "template_dir", and supporting auto conversion of a string -> list if only one is given to "template_dirs".

@derks derks self-assigned this Feb 19, 2025
@derks derks modified the milestones: 3.0.12 Stable, 3.0.14 Stable Feb 19, 2025
@TomFreudenberg
Copy link
Contributor Author

@derks thanks for positive feedback.

Let me know if I can support you in that issue.

@derks
Copy link
Member

derks commented Feb 19, 2025

Thanks @TomFreudenberg -> Does this resolve what you are seeing in Issue #745?

@TomFreudenberg
Copy link
Contributor Author

@derks - No - but I will more precise the description on the issue #745

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants