Closed vsajip closed 9 months ago
Hmmm. GitHub Actions failing, but tests run fine locally ...
$ just test
django-admin test --settings=tests.settings --pythonpath=.
Found 5 test(s).
Creating test database for alias 'default'...
System check identified no issues (0 silenced).
.....
----------------------------------------------------------------------
Ran 5 tests in 0.008s
OK
Destroying test database for alias 'default'...
$ just coverage
coverage erase
coverage run -m django test --settings=tests.settings --pythonpath=.
Found 5 test(s).
Creating test database for alias 'default'...
System check identified no issues (0 silenced).
.....
----------------------------------------------------------------------
Ran 5 tests in 0.012s
OK
Destroying test database for alias 'default'...
coverage report
Name Stmts Miss Cover
--------------------------------------------------------------------
src/template_partials/__init__.py 1 0 100%
src/template_partials/apps.py 19 0 100%
src/template_partials/loader.py 30 7 77%
src/template_partials/templatetags/__init__.py 0 0 100%
src/template_partials/templatetags/partials.py 53 4 92%
tests/__init__.py 0 0 100%
tests/settings.py 5 0 100%
tests/templates/debug.html 8 0 100%
tests/templates/example.html 12 0 100%
tests/tests.py 35 0 100%
--------------------------------------------------------------------
TOTAL 163 11 93%
Did you get a chance to take a look, @carltongibson?
Hey @vsajip, no not yet. I have a few personal issues going on right now that have kept me away. I will get to it though! Thanks for the input.
Are you up for making a few adjustments? ... Let me know if that makes sense.
Sure. I'll look at this when I can!
Great. Thanks! 🎁
and let it take a backend alias
What exactly do you mean here? Databases have aliases, sure, but template backends are a list of backends such as Django, Jinja2 etc. denoted by the backend engine class name - what does "alias" refer to in this context? Do you mean the value of the BACKEND
key in a dictionary in TEMPLATES
?
I mean the NAME
key, which you'd use in particular if configuring multiple Django backends.
I mean the NAME key
Oh, I see. That was under my radar as I've never actually used it - never had to configure several instances of the same backend with different options.
Also,
I would leave and adjust the existing example, so people have that if they need it.
Do you mean the usage example? I'm assuming the example of configuration of the loaders isn't needed, as wrap_loaders
does it and it's not needed in common usage.
There are lots of folks defining loaders by hand, so they'll find having it stated explicitly helpful.
So just leave as is, but move to where "wrap_loaders" is mentioned?
Yeah...
Option 1 is just add to installed apps.
Option 2 is use the simple AppConfig but then configure loaders yourself (either with wrap loaders or by hand)
I've pushed changes addressing your comments, but for some reason GitHub hasn't picked them up.
The GH issue appears to have resolved itself. My last commit is now showing, so you should be able to review my changes.
Thanks @vsajip 🙏
Just so you know, life is pretty full-on just now, so I may be a week or so to review this.
Awesome effort! 🎁
Oh hey, no worries! I'm using this library, liking it, and I like to give back. Take your time :smile:
@vsajip Thanks for your patience here. Just so you know, I'll looking at this now, and am hoping to do a release for a new version in the next week or so. 🎁
Should fix #10. I didn't create a separate
wrap_loaders()
function as I wasn't sure where it would be called / where it should go if called from outside this package. Would appreciate your comments!