Interested to learn more about this project

[JuroOravec]

Hi, I just found out about this project. I'm working on django-components. There, we've extended Django templates with stuff like allowing literal lists and dicts as template tag inputs, and more.

I initially implemented those extensions in Python, but I've moved them to Rust because it was horribly slow. The Rust port is not published yet (I got side tracked with writing benchmarking tests for django-components). I implemented the AST parser using Pest, which offers a BNF-like syntax.

Because of additions like the support of literal lists and dicts, some internals will have to be slightly different - e.g. django-components has to override FilterExpression (and maybe also Variable) class, in order to construct them from the AST.

That's why we're thinking of eventually making django-components into a standalone templating engine for Django. And if/when we get there, it would also make sense to eventually move some parts to Rust for better performance.

So, I'm finally getting to my point - I'd like to learn more about this project 😄

• @LilyFoote What is the scope for this project, I assume it will be a one-to-one with Django's original implementation?
• Will it include also the Library class (since, AFAIK, that's specific to the django templating engine)?
• On the other hand, I think I saw Loaders in this Rust port - I'm noob in Rust, so I wonder, does it make sense to port those too? Aren't they IO-bound?
• Once Rusty is published, would be the Rust package available too, or just as Python bindings?

[LilyAcorn]

Hey! Thanks for the interest, django-components looks like a really cool project too!

What is the scope for this project, I assume it will be a one-to-one with Django's original implementation?

Yes, the scope here is to build a fully functional template backend for Django, which can render any existing Django template correctly.

Will it include also the Library class (since, AFAIK, that's specific to the django templating engine)?

I'm leaning towards "no" right now - instead I'm hoping to just handle tags and filtered registered using Django's Library rather than implementing our own. Of course, this might change with a strong use-case.

On the other hand, I think I saw Loaders in this Rust port - I'm noob in Rust, so I wonder, does it make sense to port those too? Aren't they IO-bound?

If Django's loaders returned strings, I think we could have re-used them here. But since they return Template instances, I needed to implement them in Rust so they would return our Rust Template type. I'm also planning to implement a way to wrap loaders written in Python (#5), which would then convert Django Template instances to Rust Template instances.

Once Rusty is published, would be the Rust package available too, or just as Python bindings?

I'm currently only planning on releasing as a Python package on PyPI. However, I'm open to discussing whether it makes sense to share some internals as a crate.

[JuroOravec]

Thanks, appreciate that!

Re: Library

No strong use case, just curious. In django-components, we have this class ComponentRegistry, which keeps track of which components are registered, and (un)registers template tags from associated Library accordingly. It's still long way till this becomes relevant, but our ComponentRegistry has practically one-to-one relation with Library, so we might eventually merge them into a single class once we move django-components into a standalone template engine.

Re: publishing Rust creates

Thanks. Again, it's a long way till then, but in that case I might come back to this discussion when there'll be some parts we could reuse :)