Open ModProg opened 1 year ago
One thing I noticed is, that we could maybe allow bool
for condition or have it be true by default.
Another option would be to have an additional .teraignore
file. But not sure about that.
This is a great start, but I'd rather opt to extend the FileIgnore
struct with an enum, that gives a bit more fine-grained control over how to ignore (or rather exclude) the file. What I mean is something like an ignore type or "ignore from" value:
Skip
or All
: Simply completely skip the file from any processing and don't copy it over into the target directory. This is the current all-or-nothing default that is done for .hatchignore
and the extra ignore
rules.Template
: Ignore the file from templating, simply copying it over as-is.Copy
: Feed it into the templating engine, but don't output it to the target directory. This would solve #14.Probably "ignore from" would give a better meaning than type. Would read like "ignore from All", "ignore from Template(-ing)", and "ignore from Copy(-ing)".
Eventually, this could be extended into the .hatchignore
with special attributes, similar to how Syncthing does it. For example, have a (?t)
at the start to set the type to Template
and (?c)
to set the type to Copy
. But that's something we'd better do in a separate PR, if not completely removing .hatchignore
after all, as it's quite duplicate with the ignore rules in .hatch.toml
.
I implemented it that way now. But AFAICT there is no reason to ignore from copy but not from template.
Because if something is referenced from another template, it does not need to be templated itself.
So we'd only need these cases:
So it should be enough to have:
Unless you think we need a way to not add files to the tera context at all.
I think it might make sense to completely ignore files from templating, but still copy them over. For example, currently I use mime types to detect whether a file is binary or not, but that might not catch all the right files at all times.
By having a special rule for it, we can cope for that case and define simple copy-only file rules. Then we
So the cases you'd propose would be
IMO there is no need to actually differentiate between 4. and 5. or 2. and 3. as they would not make a difference to a user I think. Or does terra do something with the files added, even when they are not evalutat as template and would fail on e.g. invalid Unicode.
I just wanted to use this, and remembered we didn't complete it. Was there something left todo?
This supports excluding files from being executed as a template but keeps them arround to be used by templates.
This allows both files containing invalid templates without wrapping them in
{% raw %}
, but more importantly it allows macros.The problem with macros is, that they are not allowed in templates, so this is the only way to implement them.
files with
template = false
are now added totemplate_files
so they can be referenced, but they are not rendered as templates them selves.closes #14 somewhat resolves #9