Leading/trailing slash resiliency

[Joseph Nix]

I noticed this looking at #20 (note @rgommers, @goanpeca ). As of 0.3 this plugin / virtual path resolver is not resilient against different formats of supplying source_path (at least) url fragments in the config file.

In my testing with this site and a simplified config and template fragment of

[feed]
name = blogname
source_path = /blog/
url_path = feed.xml 

{{ '/blog/@atom/feed'|url }}

The jinja only correctly resolved with source_path = /blog. /blog/, blog/, and blog all failed, resulting in a broken rendered template path of blog@atom/feed. This shouldn't be so picky. I'm thinking at least the trailing slash should be optional. There may be a good reason to have to pick the presence of a leading slash though (relative v. absolute).

At the moment I'm not sure where this should to be addressed; here, core, or partially in both.

[Gonzalo Peña-Castellanos]

Hi @nixjdm :-)!

I'm thinking at least the trailing slash should be optional.

I would fix this in core?

And maybe here we could make it just work in case leading is missing?

[Ralf Gommers]

Thanks @nixjdm, that was very helpful. It's indeed pretty fragile. This worked for me:

source_path = /blog
url_path = /blog/feed.xml

and deleting filename. It seems to still generate a feed.xml in addition to blog/feed.xml, but I'll worry about that later - blog/feed.xml works now.

[Ralf Gommers]

Fixing only the trailing slash here makes sense to me.