support for pkg_resources resource management

[imbolc]

support for pkg_resources resource management

[imbolc]

Ah, ok, I've merged your PR and made new pypi release

[imbolc]

It looks like app_subdir is ignored if root_dir is specified. This seems a little counterintuitive.

Why do you think it's ignored? It returns both the templates/<app>/<tpl.html> and <app>/templates/<tpl.html>

>>> from jinja_app_loader import Loader
>>> loader = Loader()
>>> list(loader.iter_filenames('words/all.html'))
['templates/words/all.html', '/home/imbolc/0/tellmedata/words/templates/all.html']

[imbolc]

The logic is:

• try to find template at root_dir/app/template
• if it isn't exist, try to find at app/app_subdir/template

Django works with templates similar way.
It allows to redefine some templates of installed apps (eg django.contrib.admin) just with adding it to templates/app/template_name.html.

[nihlaeth]

jinja2 can do that out of the box: http://jinja.pocoo.org/docs/2.9/api/#jinja2.ChoiceLoader

try to find template at root_dir/app/template
if it isn't exist, try to find at app/app_subdir/template

I see now that you mean for app to be part of the template argument. Personally I dislike this, and would rather specify two FileSystemLoaders (the second one acts as fallback). That way you're both clearer to the user as to what you expect, and you allow the user more freedom in defining their directory structure.

[nihlaeth]

Why do you think it's ignored? It returns both the templates//<tpl.html> and /templates/<tpl.html>

let's say root_dir = '/some_path/', app_subdir = 'templates' and template = 'application/template.html'

Result

• /some_path/application/template.html
• application/templates/template.html

Expected result, if I go along with including application in template

• /some_path/application/templates/template.html
• application/templates/template.html

[imbolc]

How would you emulate the current behavior with the ChoiceLoader?

/some_path/application/templates/template.html

This way if some_path the root of your application you'd create new folder there for each subapp which template you want to redefine. If som_path is not the root, the /templates/ part looks redundant for me, why do we need it?

[nihlaeth]

How would you emulate the current behavior with the ChoiceLoader?

loader = ChoiceLoader([
    FileSystemLoader('/some_path/application/'),
    PackageLoader('application', 'templates')])

This way you can't define the application with the template, you'd set the template to template.html.

You could even do this:

loader = ChoiceLoader([
    FileSystemLoader(['/some_path/user_application/', '/some_path/original_application/']),
    PackageLoader('original_application', 'templates')])

This way if some_path the root of your application you'd create new folder there for each subapp which template you want to redefine. If som_path is not the root, the /templates/ part looks redundant for me, why do we need it?

I get your train of thought now, and where it clashed with mine. I used the root_dir to point to the package directory, assuming that templates would be added to it.

[imbolc]

Look, with jinja_app_loader, you can make as much application as you want if they has the same files structure like <app_name>/templates/<template_path>. And you can redefine any of its templates in the root templates folder. But if I understand right, with the ChoiceLoader you should add into it each application, or I miss something?

[nihlaeth]

Look, with jinja_app_loader, you can make as much application as you want if they has the same files structure like <app_name>/templates/<template_path>.

With the choice low you don't need the same directory structure.

And you can redefine any of its templates in the root templates folder.

No, because you define the app name in the template, it's actually hard for an end user to overwrite the templates. That's why I added that configuration option for aiohttp-login.

But if I understand right, with the ChoiceLoader you should add into it each application, or I miss something?

To make an example of aiohttp-login: that package would have nothing to do with the ChoiceLoader, aside from the example. It's actually the code using aiohttp-login that should define an instance, and choose the fallback order and from which locations it loads its templates. It's important to leave that choice with the end-user, since they might be using multiple libraries that use templates, and need a complicated fallback order.

Did I answer your question with that? Or should provide a more involved code example?

[imbolc]

No, because you define the app name in the template, it's actually hard for an end user to overwrite the templates. That's why I added that configuration option for aiohttp-login.

Yes, I remember, you'd like to install your site with pip. So would you make changes into jinja_app_loader for this case?

[nihlaeth]

That has very little to do with pip actually. And I don't need any changes in jinja_app_loader since I don't actually use it. Adding those configuration options to aiohttp-login allows me to overwrite the standard templates and removed the app name from them, so I can use a jinja2 loader instead.

I think we are having this discussion because I discovered that the common templates also had their application prepended, and I added a configuration option for that as well. From what I understood, you would rather I change jinja_app_loader to support pkg_resources resource manager API. The thing is, I would still need you to merge the pull request in question, since your hardcoded the application name.

if you're not happy with all that, I can just let my fork diverge.