nf-core lint searches vim tmp files

[erikrikarddaniel]

Files matching .*.sw? should probably not be included in what's linted.

[ewels]

hah, oops.. Which linting step is this?

[ewels]

Hi @erikrikarddaniel,

Are you able to confirm which linting step you had this issue with? Just so that we can be sure to track down the error.

Cheers,

Phil

[erikrikarddaniel]

I'm afraid not and I can't reproduce it now... I have opened the main.nf in vim and have a .main.nf.swp file but do not get any warnings from that. (I do get a number of other warnings though: conda packages not up to date and a few TODOs, but not in vim files.) nf-core is at version 1.7; not updated since November I believe.

[ewels]

I don’t think that the linting looks at main.nf at all, or any of the config files. It checks those by running nextflow config - so it’s up to Nextflow to ignore temp files for those. It’s possible that the linting would pick up on temp files for other stuff I guess, but I’m not sure which files or tests would be affected by this.

If it’s ok, I’ll close this issue now. But please reopen if it happens again with the specific error / warning that you get from a temp file and it should be easy enough to track down.

Phil

[fasterius]

I'm getting similar behaviour with TODO strings and vim undo-files (<file.extension>.un~): even TODOs that I've fixed are still showing up in the undo files (as they are part of the files' histories), which is a bit annoying. A workaround is of course to just store my undo-files in my home folder, but I prefer them to be in the same directory as their original file.

[ewels]

Fix is to improve the code that ignores files in the check_pipeline_todos() function:

tools/nf_core/lint.py

Line 1167 in 8f3c482

ignore = [".git"]

At the moment it will only work with exact filename matches though, so will need to be extended to use fnmatch to match file patterns as well.

[ewels]

Suggestion for glob patterns: *~ and *?

[fasterius]

Should work, though I don't know if any others use *~. Either use that or *.un~if you want to be more specific.

[ewels]

I can't see why we would need to commit any files ending in ~. Easy enough to change / manually add if we do anyway, so I'd rather keen it broad I think.