Move all of the template creation into askama_shared #647
Conversation
askama_shared/src/derive.rs
Outdated
| @@ -0,0 +1,107 @@ | |||
| extern crate proc_macro; | |||
There was a problem hiding this comment.
So I tried this in the past and this doesn't work. As far as I remember, you should not import proc_macro anywhere except in a proc-macro = true crate. However, what we can do is convert to proc_macro2 types in askama_derive and then pass that into askama_shared.
I don't love the derive name of this module, given that I think we might want an attribute macro at some point in the not too distant future, too. Can we use macro as the name, or is that a keyword?
There was a problem hiding this comment.
I replaced proc_macro by proc_macro2.
Actually, I guess I could move everything into generator.rs. It's only 100 lines as is.
There was a problem hiding this comment.
Actually, I guess I could move everything into generator.rs. It's only 100 lines as is.
That probably makes sense for now, although it just means we should start splitting that up since it's already pretty big. Good start, though!
Before this PR the handling of integrations was done both by askama_shared and askama_derive. This diff lets askama_shared do the work. This will prevent problems like #629, when both packages might come out of sync.
Kijewski
force-pushed
the
pr-integrations
branch
from
ca698aa
to
9cee3eb
Compare
All the hard work in askama_derive was actually done in askama_shared. This PR removes the back-and-forth interaction between the two crates. Now askama_derive is a single re-export of `#[derive(Template)]` which has to be done in a proc_macro crate. This most likely means that askama_derive is "final", unless another derive template needs to be introduced in the future.
Previously askama_shared exported most of it's internals, so askama_derive could use them. This is not needed anymore.
Kijewski
force-pushed
the
pr-integrations
branch
from
9cee3eb
to
ac281dc
Compare
Kijewski
force-pushed
the
pr-integrations
branch
from
ac281dc
to
c8a7ab5
Compare
| @@ -1,6 +1,6 @@ | |||
| [package] | |||
| name = "askama_derive" | |||
| version = "0.11.2" | |||
| version = "0.12.0" | |||
There was a problem hiding this comment.
I un-exported a bunch of symbols. Older askama_shared versions would break with this update. Every item in https://github.com/djc/askama/blob/main/askama_derive/src/lib.rs#L8-L10 is gone after the PR.
There was a problem hiding this comment.
I removed the features section, because they are now handles in askama_shared.
I am not 100% sure, but I guess if I re-added the features, incrementing the patch version only should be fine.
| @@ -1,6 +1,6 @@ | |||
| [package] | |||
| name = "askama_shared" | |||
| version = "0.12.2" | |||
| version = "0.13.0" | |||
There was a problem hiding this comment.
I un-exported a bunch of symbols. Older askama_derive versions would break with this update. Every item in https://github.com/djc/askama/blob/main/askama_derive/src/lib.rs#L8-L10 is gone after the PR.
The traits Template and DynTemplate need to be in sync with askama_shared's generator. #647 consolidated the template crating into askama_shared, this PR moves the trait itself.
Before this PR the handling of integrations was done both by askama_shared and askama_derive. Let askama_shared do the work. This will prevent problems like #629, when both packages might come out of sync.
This PR removes the back-and-forth interaction between the two crates. Now askama_derive is a single re-export of
#[derive(Template)]which has to be done in a proc_macro crate.This most likely means that askama_derive is "final", unless another derive template needs to be introduced in the future.