FYI <https://github.com/pantsbuild/pants/pull/1767...
# development
b
FYI https://github.com/pantsbuild/pants/pull/17677 adds a new native function which filters paths based on gitignore-style globs. If that's something you've ever been interested in 🙂
w
you can do that with
FilespecMatcher
… not sure if it aligns with your usecase though
👀 1
1
b
No docstring 😞
w
it’s important to actually re-use the compiled matcher, hence the class
b
But also, hmmm
(Interesting that if I websearch
zglob
I don't get very helpful hits 🙈 )
I'll try using this, Although damn my grep-fu didn't help me find this
w
yea… “filespec” is a weird holdout name from who knows when.
1
b
Oh, this is slightly different because the paths must be "rooted"? E.g.
*.py
doesn't match
sub/foo.py
.Maybe thats OK
w
it’s consistent with our other matching. if you want python recursively, you use
**/*.py
b
Is there a spec I can nudge users towards?
My search engine doesn't do well when searching "zglob"
w
in general, we claim to be compatible with git globs, so https://git-scm.com/docs/gitignore is roughly the spec (with some exceptions, as you pointed out)
not sure where you found a reference to
zglobs
, but iirc, both “filespec” and “zglobs” are older terminology from v1… zglobs was a reference to
zsh
globs
b
src/python/pants/source/filespec.py
👍 1
lists "zglobs"
w
but it’s very unlikely that we are compatible with
zsh
at this point, given that i have never looked at it, heh
b
Ok then my next PR is ready, save for documenting the globs. I guess, why doesn't filespecmatcher just use the
ignore
crate? Then we can handle user input and shed the spec docs
w
the goal is consistency with
PathGlobs
, which have a separate implementation in order to 1) be lazy,, 2) be memoized, 3) track filesystem changes
in order to use the
ignore
crate to implement path glob expansion, we’d probably have to plug in an async virtual filesystem below it… they may be amenable to that, but i don’t know
b
That might relate to the open issue of nested gitignore files too
w
yes