Feature: Allow yml extension

[tbrlpld]

Description

So far, the context YAML files had to have the .yaml extension. YAML files often also use the .yml extension. This PR adds a second attempt at finding the YAML file with the .yml extension after the .yaml extension has failed to produce a result.

The second attempt is simply enabled by adding a second nested try-except-block. I am not sure this is the most elegant solution, but it works and seems easy to understand.

Fixes #161

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas -> No hard to understand areas.
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I have added an appropriate CHANGELOG entry

[thibaudcolas]

@tbrlpld this seems spot on to me – we have to attempt to read both paths either way, so I don’t think there would be much of a better way. I have a feeling this is overkill but we could cache whichever file extension was loaded successfully last for a given pattern to avoid the extra IO when a site consistently uses .yml?

To finish the PR, I’d additionally want to see:

• A unit test for this
• A mention in the documentation, replacing the "Always use .yaml" we have here: https://torchbox.github.io/django-pattern-library/reference/api/#yaml-structure

[tbrlpld]

@thibaudcolas I have pushed changes according to your review.

Regarding the caching: I also think that would be overkill. Especially in larger projects I can imagine that both extensions could occur when no linter or CI checks preventing it from happening. In that case it would be particularly confusing why the files are not recognized while they would work in another project which is consistent.

If we wanted to allow projects to be consistent, we could add a setting, but I am afraid that could also cause confusion because you would need to know how it project is configured.

I am not sure, but would using glob to check for file existence save the additional IO?

[thibaudcolas]

@tbrlpld thank you, I’ll try to review this once I get the chance. Re glob – I doubt it’s worth it. We’d have to do 1 scandir with glob, then the 1 file read, so it’d be two IO calls for all cases rather than the "1 or 2" situation we’d be in here.

[bcdickinson]

Thanks Tibor, this is great.

[tbrlpld]

Thanks for reviewing @bcdickinson