relative template paths and include_str support

[henke443]

I would want to have the feature.html template be in the same folder as feature.rs.

It would be cool if you could do either one of:

A)

pub static FEATURE_TEMPLATE_HTML: &'static str = include_str!("feature.html");

#[derive(Template)]
#[template(source=FEATURE_TEMPLATE_HTML, ext = "html")] 
struct featureTemplate<'a> { 
    name: &'a str,
}

B)

#[derive(Template)] 
#[template(path="./feature.html")]  // And maybe just path="feature.html" is using the toml dirs? Like how "import" works in nodejs
struct featureTemplate<'a> { 
    name: &'a str, 
}

[djc]

I think I'm open to either of these (assuming the implemention doesn't add too much complexity), if you want take a whack at implementing this. Have a look at https://github.com/djc/askama/blob/main/askama_derive/src/generator.rs#L81 and https://github.com/djc/askama/blob/main/askama_derive/src/input.rs#L11.

[Kijewski]

The first option is impossible to implement. The proc macro will only see the token FEATURE_TEMPLATE_HTML, and it is currently not possible to evaluate the context. (E.g. that's why #[doc = include_str()] works, but #[doc = SOME_CONSTANT] does not.)

But I like the second option!

[Zonnex]

Yes please! I REALLY wish to co-locate the html file with the rust file. I've actively looked for alternatives to askama that does this, but I haven't found any, and I don't want to use anything else because I really like how askama does things.
I doubt I'm able to implement this myself, I'll take a look but I otherwise that someone else is able to!

[qwfy]

I'm currently using this:

Create an empty templates directory, then use a relative path:

#[derive(Template)]
#[template(path = "../src/some/thing.yml")]
struct Some {
    foo: String
}

Downside is that you have to hard code the entire path

[BuriKizilkaya]

Is there any progress?

[djc]

No, I guess there isn't. Do you want to submit a PR?

[BuriKizilkaya]

I will try....

[andrewbaxter]

The first option is impossible to implement. The proc macro will only see the token FEATURE_TEMPLATE_HTML, and it is currently not possible to evaluate the context. (E.g. that's why #[doc = include_str()] works, but #[doc = SOME_CONSTANT] does not.)

But I like the second option!

I think ATM the second option is also impossible to implement: rust-lang/rust#54725 (going on 6 years)

include_str and I assume doc are currently using compiler magic to do it IIUC.

i.e. I don't think there's a way to do this at the moment.

[joshka]

i.e. I don't think there's a way to do this at the moment.

Use a nightly compiler, add cfg flags to your RUST_FLAGs and this PR does the trick:
#1112

Needs a bikeshed discussion on the feature flag name (as relative-paths is a little ambiguous for my liking), but it works.

From an implementation perspective, it made sense to me to just make the current source folder the first folder that gets searched for the template, rather than having to use any change in configuration. This allows some things to be put in the configured template folders and some things to be put in the relevant src folders. So the syntax to make this work is just #[template(path = "foo.html"].

One thing that is an open question is what to do when paths are specified in the config. I currently did not make this allow the relative paths, but it would be easy enough to extend the PR to do that. Requires a decision on this. (I haven't used config files generally so I don't really have a position on what is right there).

Additionally, it might be worth considering looking at files up the directory tree in order to have the ability to define templates that are generic / reused / default, and which can be overridden. This might be useful for situations where you have a standard list format and then have a template defined that will just pick that up from the parent folder, but sometimes want to override the list view. Likely outside of the scope of the PR, but worth considering