A few thoughts: I like OPTIONS, I think it's a good idea for the reasons Carl suggested.
It would be preferable to have the backend configuration outside of `django.template`. `django.templating` seems reasonable, but even `django.template_backends` might be appropriate as it only contains backends. Assuming we go for the "subdirectory" based convention for app directories (option 4?) it would seem appropriate to make this configurable. In particular I can imagine a possibility where you may want multiple instances of the same backend with different configuration (e.g. different jinja extensions which conflict to support multiple pluggable apps). The loading problem is the only obvious flaw I can see here. It's a weird use case though. I agree the DEP needs to specify more clearly what happens with `render` and friends. I also think there's potential merit to Option 1 (engine=) support on these APIs even with Option 4 - there may be times you need to force the use of a particular engine. Marc On 3 November 2014 22:54, Carl Meyer <[email protected]> wrote: > Hi Collin and Aymeric, > > On 11/03/2014 03:26 PM, Aymeric Augustin wrote: > > Hi Collin, > > > > It’s exactly the right time to discuss APIs :-) > > > > After pondering your proposal, I'm still +0 on consistency with > > DATABASES and CACHES, but I'll make that change if other people agree > > with you. Does anyone else have an opinion on this? > > > > Thanks, > > > > -- > > Aymeric. > > > > > >> On 3 nov. 2014, at 01:50, Collin Anderson <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> Hi Aymeric, > >> > >> Thanks for all of your work on this. Am I too late to discuss the > >> settings? > >> > >> I don't see much advantage to the OPTIONS dict. It is consistent with > >> DATABASES, and it separates the engine specific settings from the > >> common settings. However, it doesn't seem like that helpful of a > >> distinction to the user, especially considering there's only 3(?) > >> non-OPTIONS settings. It seems like it only opens up the door to > >> misconfiguration. Could we just pop-off the 3 common settings when > >> configuring the template engine? > > I favor keeping OPTIONS. I don't think OPTIONS will be significantly > confusing to beginners (it may even provide a useful hedge between "the > basics" and "the advanced knobs"). > > Once you are doing anything beyond the basics, the distinction between a > setting that is handled specially by Django vs one that is just passed > as-is to the template backend is an important distinction to keep clear. > > OPTIONS provides clear indication (without referencing the docs) which > settings you can expect to provide to any template backend with > equivalent effects, and which ones are engine-specific. I think losing > this clear distinction is likely to result in much more > mis-configuration frustration than OPTIONS will. > > Carl > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/5458079E.70104%40oddbird.net > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMwjO1Gx_8vxCVdQHwnyQxPTznBG-BhAL-h7KtMeRgrXzjf5DQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
