You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We decided to remove the numbers and use the episode order feature (https://carpentries.github.io/lesson-example/03-organization/) because we wanted to avoid renaming all subsequent files in case a new episode is added and fits somewhere in the middle following the teaching logic.
Note: I have checked locally that using underscores (vs. using dashes) in the filenames does not raise the warning (at least past the number of the filename). We opted for using underscores influenced by Python.
Thanks.
The text was updated successfully, but these errors were encountered:
The episode filename pattern regex expects these to start with a number:
styles/bin/lesson_check.py
Line 45 in e3808e8
However, in
https://github.com/carpentries-incubator/SDC-BIDS-dMRI
We decided to remove the numbers and use the episode order feature (https://carpentries.github.io/lesson-example/03-organization/) because we wanted to avoid renaming all subsequent files in case a new episode is added and fits somewhere in the middle following the teaching logic.
Done in here:
carpentries-incubator/SDC-BIDS-dMRI#67
Partially related to the above is that we have nested episodes:
carpentries-incubator/SDC-BIDS-dMRI#47
And numbered file naming is somewhat limited when using a nested filename convention.
Hence, we now find ourselves with style warnings:
https://github.com/carpentries-incubator/SDC-BIDS-dMRI/runs/2401702149?check_suite_focus=true#step:16:9
because we do not have numbered filenames.
I know this might not be easy, but could the filename check be skipped if the repository uses the episode order feature in the
_config.yml
file?This might need to be accompanied by changes (or further explanations) in the
Locations and Names
section:https://carpentries.github.io/lesson-example/04-formatting/index.html
Note: I have checked locally that using underscores (vs. using dashes) in the filenames does not raise the warning (at least past the number of the filename). We opted for using underscores influenced by Python.
Thanks.
The text was updated successfully, but these errors were encountered: