Changes

• Add support for multiple search paths: want to be able to specify separate (partial) template folder (e.g. under a theme), some main HTML pages in another directory, and possibly other directories containing Markdown files for article pages to be rendered. It’s non-trivial how I would symlink these all together under one single templates folder like vanilla staticjinja wants, since something like the notes need to sit at the root of the site and I can’t symlink new folder contents automatically.
• Remove dependence of static paths relativity to search path: vanilla staticjinja wants to specify static paths as paths relative to the search path you gave. This will no longer make sense with many search paths, but I also just don’t like the idea of having to do this in the first place.
• Additionally, staticjinja expects static files to be within a specified search path. This feels a little weird; you can’t tell it about static files that are outside template directories. ACTUALLY, I take this back. I was sort of ignoring the semantics of a “search path” with this observation: they are literally all the paths you want to search for site files. So with this perspective in mind, you just need to include all of the non-overlapping paths with content you want on your site in the searchpaths variable. These will all come together under one root, and each directory should locally look like a slice of the exact site structure that you want (i.e. the same directory hierarchy will persist into the output). The main render process will then glue these all together under one output folder. For static files, you just need to be sure to also say which of those internal folders have static files in them (or don’t, it really doesn’t seem like Jinja cares about messing with them anyway). Note that these static paths will all be relative to their respective search path, and it doesn’t matter if you don’t know which static path is supposed to be under which search path. Because they all render to the same place, you can know what each static path must be called, i.e. you have to be on the lookout for overlapping names from the very beginning. This also in theory enables you to split the structure of your site into separate folders however you’d like. Even if you now have a static-only folder outside of any templates, as long as that folder has the static structure you want in the final site you must provide it as both a search path, AND the internal folders or root files as static paths. The only downside to this is there is not a good way to work around having a static only folder with flat files independent of any other folders; it would have to be doubly nested, as the outer folder would be the search path, and once inside that search you need the same structure you want to see on your site. If you were to actually want all the files sitting at the site root, you would need to manually specify all of the individual files as “static paths” (however here I’d likely just leave it and let Jinja do nothing but put those in the output). All in all: regardless of filetype, you need to specify all discrete pieces of your site as search paths. Those search paths will be pieced together during the render process, and the local structure in each of the independent folders will merge under the same root. You then need to specify the names of the static paths/files that are inside the search paths already, as paths relative to whichever search path they happen to be in.

Note: this fork is being developed to help my incorporate my desired changes into the staticjinja core, allowing me to more intuitively build my own file conversion pipelines. I intend to use staticjinja as an “engine” of sorts in this way, centralizing all the rules/contexts I want to apply to certain files, tracking/rendering input files to an output directory, and automatically serving/rebuilding these directories when needed. In this sense staticjinja can be very general (i.e. it can used effectively without any HTML files, or even using Jinja templates). That said, the utilities that build the context for the remainder of conversion pipelines are still complex and share some reusable code. The Panja project, while originally started to do the job of staticjinja, will just be used to house all the additional pipe-building utilities that go into the staticjinja core (so the original panja project is still useful in this way).