-
-
Notifications
You must be signed in to change notification settings - Fork 209
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Broken feature unification when multiple packages depend on askama
#810
Comments
Yeah, not sure if there's a solution for this. The easiest solution is probably to have both of your crates enable with |
Hm, I think in this case you have to copy https://github.com/djc/askama/blob/ea8be44/askama_axum/src/lib.rs and call Features are additive, and I we add an "anti-feature" like "dont-implement-into", then this would be the same as if you omit "with-axum" in your main crate. |
The problem is that the crate where this is happening is a dependency of a dependency of a dependency... . I can Idea: Possibly, instead of relaying on cargo features to build the right code, somehow the user of the macro should inject the list of backends they're interested in. Possibly This way If you can somehow make an |
Having to decorate each type with all the integrations needed seems like a pain in the ass. But, we could set this up in the configuration? So you declare in the |
If that's possible, then it does seem like an improvement. |
I am experiencing this issue as well but with
|
@5iddy you should be pulling the |
I have encountered the same issue as @dpc. To give some explanation as to why it is non-trivial to solve this: When the askama/askama_derive/src/generator.rs Lines 171 to 183 in b8697ba
This code might not be called by the crate which depends on In other situations, it would just mean adding In short, making this work as-expected would require a deep rework of the Askama workspace. |
I'm open to reviewing a rework of the Askama workspace if we think there is a way to solve this, but the right way to solve this is not obvious to me. In particular, having all the integrations be Cargo features in the askama crate is not a workable situation -- that is what we had before, but it leads to issues because the Askama crate ends up conditionally depending on a whole lot of other crates some of which might conflict (like, Rocket might depend on a different version of hyper than Axum, which is a pain in the ass to maintain). The problem here is that we have Askama usage in different crates, and whether or not to generate code for an integration is propagated via Cargo features. Askama crates get compiled with a unified set of features, while the support code necessary for the integration might not available in each crate that has templates in it. However, it's not obvious how procedural macro invocations across crates might communicate with each other (alternatively, how we could block procedural macro invocations across crates from communicating with each other, I suppose?). |
I'm trying to make a workspace that in two different places of dependency tree uses
askama
One imports only
askama
, the other oneaskama_axum
. The one that only imports askama fails with:Seems to me that the other crate enabled
with-axum
feature, andaskama_derive
is being picked up by theuniffi-rs
so it now generates code that wants to accessaskama_axum
, which is not a dependency of it.I've read through #588 (comment) which seems somewhat related.
Unless I'm missing something somewhere, this might be a hard circle to square. Downstream crates with different extenson-sets, can't share the
askama_derive
, it seems.The text was updated successfully, but these errors were encountered: