Matching filename over paths

[kimt33]

In matches_filefilter, fnmatch is used to check if the given filename satisfies the given set of patterns using the UNIX filename matching patterns. I'm not too sure if this is correct, but going by how I use filename matching in my terminal (eg ls), I would think that *py search only the current directory, */*py would search all directories within the current directory, and so on. However, fnmatch simply treats the given filename as a string and assumes no directory information. For example, fnmatch('foo/bar.py', '*py') would return True. In fact, we can assume that fnmatch expects a filename specifically rather than the file path.

Right now, each pattern used in matches_filefilter should start with * if the file is located in any of the subdirectories. It's weird that if I want to find all python files (in all directories), my pattern would be *.py, but if I want all python files that start with test_, I would need to write *test_*.py or */test_*.py. I would expect that if *py is valid, test_*.py is also valid.

[tovrstra]

@kimt33 I'd like to solve this by using the same syntax as in recursive globbing, which fairly well-established.

Recursive glob is supported in the Python standard library in glob.glob, see https://docs.python.org/3/library/glob.html, but the fnmatch.fnmatch function in the standard library does not have this feature yet. There is an issue for this: https://bugs.python.org/issue28718

I'd suggest we use the following package: https://pypi.org/project/pywildcard/ Would that work for you?

[tovrstra]

The following implementation of recursive glob in an fnmatch-like function seems healthier than pywildcard: https://github.com/facelessuser/wcmatch

[kimt33]

And I'm not sure if I remember correctly, but within the context of matches_filefilter, the list of files generated first as absolute/relative paths and then passed into matches_filefilter. These files are then checked with some set of rules (following some syntax) to see if they meet the conditions set by the rules.

If the syntax for the rules changes significantly (i.e. tests get broken), then this should be equivalent to breaking the API and may break some of the existing cardboardlint.yml's. Since the travis.yml by default clones the github repo (I think), the existing CI systems may break, but it will be easy enough to spot. If anyone uses cardboardlint locally, then they will see this weird discrepancy between local and Travis. Not a big problem, I think, since only a handful of people (Farnaz and me?) have it integrated into their package.

But either way, I'm on board with either of your suggestions. I thought that the use of fnmatch was rather hacky to begin with.