Add support for compound file extensions.

[holden-nelson]

Created a new class ReaderTree that is an infinitely
nested defaultdict containing components of the extension.
See comments on PR #2816.

Pull Request Checklist

Resolves: #issue-number-here

• Ensured tests pass and (if applicable) updated functional test output
• Conformed to code style guidelines by running appropriate linting tools
• Added tests for changed code
• Updated documentation for changed code

[avaris]

I'll go over it in more detail when I have more time but glanced over it briefly and this looks promising, thank you :). I think Generators._include_file also needs some adjustment to support compound extensions. Otherwise I don't think it would include foo.bar.baz even if there was a reader for bar.baz. Building on the endswith idea, this might do the trick:

if extensions is False or basename.endswith(extensions):
    return True

[holden-nelson]

Mmh. Right. Forgot about __include_file. I see how that would work. I'll edit my PR.

[holden-nelson]

Edited.

[holden-nelson]

Hello,

Poking around the source code I believe there is another location that is affected by this change.

In the contents.py file, the __init__ method of the Content class generates a slug. If the SLUGIFY_SOURCE is set to basename it uses everything to the left of the last dot to create the slug. So for a file ending in .md.html the .md will be passed into the slugify function.

Additionally, the SourceFileGenerator class grabs the basename of the source files in the same way.

Should I continue working on my PR and write code to account for these issues?

[holden-nelson]

Also pushed a small change that should fix the linter failing :)