So, as discussed before, I have a compiler branch of
fluent.runtime, which was ready over a year ago, but has been held up on merging first of all due to PR 92 which has not made much progress in a while. In addition there are probably lots of other decisions that would need to be made, like handling of escaping which we never came to consensus on.
This has meant that for over a year there has been no straight-forward installation process for django-ftl, which is unfortunate if it wants to see any adoption.
Since then, lots more things have happened, like a new API in the main branch
fluent.runtime. The new API is harder for me to adapt the compiler backend to, and it looks less and less likely that the compiler branch will ever be merged.
I’ve also become aware of lots of other ways that I could improve the compiler interface if I wasn’t constrained with compatibility to the resolver interface. For example, after reading the thread on message references and different kinds of fallback, I realised this is something I would want to do at compile time, not runtime, and before then I was already thinking that the interface that django-ftl really wants is just very different from either the old 0.1
FluentBundle API or the new 0.3.0 API. Compilers and interpreters just work differently sometimes.
So, I’d like to propose that we split this branch out into its own package. In fact that seems the only way for it to make any progress.
The next question would be, where should that package live? For me, I think it should live outside the python-fluent project (but could be linked as an alternative implementation). We could call it
fluent_compiler on PyPI, and it would probably live under the django-ftl GitHub organisation. Although it would continue to be agnostic as to web framework, it would first of all be designed to support my needs in django-ftl just like
fluent.runtime will first of all be designed to support Bedrock’s needs.
In the future, there is nothing to stop us moving it back under python-fluent, or indeed being packaged as
fluent.compiler instead of
fluent_compiler, but for now that just seems to be an obstacle.
How does that sound?