Skip to content
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

Make askama_shared::parser module public #760

Closed
GuillaumeGomez opened this issue Jan 7, 2023 · 11 comments · Fixed by #834
Closed

Make askama_shared::parser module public #760

GuillaumeGomez opened this issue Jan 7, 2023 · 11 comments · Fixed by #834

Comments

@GuillaumeGomez
Copy link
Collaborator

Is there any reason for this module to be private? Making it public would allow to have access to the parser directly.

@djc
Copy link
Owner

djc commented Jan 7, 2023

What branch are you looking at? What's your use case? See discussion in #748 and the changes from #687.

@GuillaumeGomez
Copy link
Collaborator Author

I was looking at the docs from the last published version. My use case is to be able to write my own proc-macro with askama parser (different needs and eventually smaller).

@djc
Copy link
Owner

djc commented Jan 7, 2023

What different needs? Smaller in what dimension?

@GuillaumeGomez
Copy link
Collaborator Author

Different needs in the storage (compile-time generated hashmap which updates templates in case they're updated) and smaller in term of deps and code (syn is very big).

@djc
Copy link
Owner

djc commented Jan 7, 2023

Would you be interested in contributing your synless derive code here? I would be open to entertaining it (though I would like to understand this plan in more detail).

As for the compile-time stuff, I've been contemplating an API that lets you run codegen asynchronously (for example, I have a bunch of code that regenerates only in an integration test so it fails in CI if the generated code is out of date). If this would address your issues, we could work on it in this repo.

@djc
Copy link
Owner

djc commented Jan 8, 2023

Further thoughts: is this driven by rustdoc needs? Is there a discussion in Zulip or in another repo somewhere that I could look at about the concerns?

@GuillaumeGomez
Copy link
Collaborator Author

Would you be interested in contributing your synless derive code here? I would be open to entertaining it (though I would like to understand this plan in more detail).

Sure. The plan is basically to be able to get rid of the proc-macros by settting up the parser "by hand" (and of course, if possible at compile-time).

And it's not a rustdoc need but a personal one. So no discussion that can be seen anywhere.

@djc
Copy link
Owner

djc commented Feb 1, 2023

Sounds like a good plan, want to submit a PR with what you've got so far?

@GuillaumeGomez
Copy link
Collaborator Author

Need to clean up things a bit. A bit under water currently but I'll try to send a PR as soon as possible.

@djc
Copy link
Owner

djc commented Feb 1, 2023

No hurry!

@djc
Copy link
Owner

djc commented Jul 3, 2023

#834 extracts a parser crate.

@djc djc closed this as completed in #834 Jul 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants