Open fabianegli opened 2 years ago
Do the gatekeepers have any thoughts about this? Or reasons not to make more use of pathlib?
Happy to move to Pathlib 👍🏻 Reason we're using os.path
is simply that I was not aware of Pathlib until pretty recently. My fingers are used to the os lib but from what I've seen pathlib looks nicer so happy to change. Presumably progressively, as os operators are numerous here to say the least.
That snippet you linked to as the example is particularly nasty! 😅
Description of feature
This repo uses many different ways to handle paths. Plain strings,
os
and pathlib. Currently, most path handling is done withos.path
. The reason to propose the pathlib.Path option is that it also has the convenient .is_dir, is_file and .glob functions as well as a nice path composition API and even operators.Do the gatekeepers have any thoughts about this? Or reasons not to make more use of pathlib?
As an example: https://github.com/nf-core/tools/blob/e0d00d3e09a996f59eb5ce6ebc4795452a5b1d39/nf_core/modules/nfcore_module.py#L32-L35
If
module_dir
would be apathlib.Path
Line 32 to 35 could be a single line:This would also solve an unexpected behaviour if the pipeline resides in a nested folder structure, with multiple non-consecutive levels named "modules",
self.module_name
becomes a path. (There are of course solutions to this issue without pathlib.Path, but I think it is one nice example how pathlib.Path can help reduce complexity.)