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