Fix --full-docs-dir regression

[CasperWA]

Try to only use PurePosixPath as a middle stage towards str or Path.

Fixes #174

Test full_docs_folder input:

• Test an individual folder name and that all files in the folder get the special option added.
• Test a subfolder (using POSIX path notation (forward slashes)), ensuring it also works in Windows via the CI tests.

[codecov]

Codecov Report

Merging #175 (ac5cfc7) into main (cca467e) will not change coverage.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main     #175   +/-   ##
=======================================
  Coverage   71.42%   71.42%           
=======================================
  Files           9        9           
  Lines         567      567           
=======================================
  Hits          405      405           
  Misses        162      162           

Files Changed	Coverage Δ
ci_cd/tasks/api_reference_docs.py	64.58% <100.00%> (ø)

[sygout]

Do we have some template repos for testing the changes?

[CasperWA]

Do we have some template repos for testing the changes?

Not really. But I can point to this branch for a CI run in the repository where I noticed the error?

[sygout]

Do we have some template repos for testing the changes?

Not really. But I can point to this branch for a CI run in the repository where I noticed the error?

Ok. I was just thinking that it would be nice to have some reference repos where we can test the changes in the CI/CD prior to merge but maybe it is not really possible in practice?

[CasperWA]

Ok. I was just thinking that it would be nice to have some reference repos where we can test the changes in the CI/CD prior to merge but maybe it is not really possible in practice?

No, it's a great idea! I've been thinking the same. But I've come to the conclusion that if it's not easily managed and also doesn't include a major part of the use cases and edge cases it's simpler/better to keep the actual repositories as "reference repos".

In reality, the CI workflows should be where we test these things through reference repos and similar, which might also be possible with a fancy setup, but (for me at least) it would take a rather long time to setup in a satisfactory way.

I think the main issue for me goes back to the question, when everything has been setup and is running, whether it will then properly represent all relevant use and edge cases. And I'm not convinced of that case.

[sygout]

Thanks for the explanation and good that it is recorded in the PR. I will approve it now.

[CasperWA]

Anyway - for this specific issue, I can test it locally in different ways. The one I've chosen is to use this branch as the pre-commit hook revision in the relevant repository (in this case OPTIMADE Gateway), where I found the regression.
Using this branch to run the hook the regression is fixed.

Note, this is when running on a WSL 2 Ubuntu system with Python 3.8.10.