Match pages by regexp not just by glob

[spanezz]

(From a conversation wtih @DonKult)

I have a silly local patch adding it as an additional parameter as globs sometimes aren't enough, but somehow I think it should be possible to annotate site_pages(path= somehow that I am passing a regex rather than a fnmatch which is then translated to a regex.

I can think of two ways:

1. if path is a regexp object, use it directly. Export function to the jinja2 templates that is an alias to re.compile. It could be called 'regex', 're', or 'R'.
2. add another argument path_re which, if present, overrides path and is used as a regexp

As I tried to explain I did 2., but I don't like it, so yeah, 1. would be nice. I would recommend a not too generic/short alias though.

Ok. Let's try and accept a regexp object for path, and export a regex() function to the templates.

[spanezz]

Another option, is to decide that if the path argument starts with ^ or ends with $, then it's a regexp. I recall seeing some other software do it, although I don't recall which one.

One can still provide the regex() function to the templates, for explicit marking.

[DonKult]

On Sun, Dec 15, 2019 at 04:37:01AM -0800, Enrico Zini wrote:

[…] if the path argument starts with ^ or ends with $, then it's a regexp. I recall seeing some other software do it […]

cough apt cough

Sort of at least: on the commandline it is more accepting (just needs to look roughly like a regex to be tried as such – would personally prefer if it would only act on ^$ …) while in apt_preferences it assumes regexes are wrapped in // – but in staticsite / is a normal and usual character so better not go there.

Long story short, would work & would have been my alternative suggestion if I hadn't forgotten about it at the time I wrote the reply.

[spanezz]

Aah, right! (I really couldn't remember that apt did it!) So from your experience not only it's a viable option, but it didn't have particular downsides so far. I think we have a winner.