-
-
Notifications
You must be signed in to change notification settings - Fork 615
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support nested .gitignore files in --pants-ignore-use-gitignore #5682
Comments
How would this work? Mind writing an example please? |
I think that I was thinking...?:
Not a big deal though... not sure the usecase is that important. |
Bumping the priority on this. Filesystem specs make it more important than in the past. E.g., |
But note that repos can have non top-level .gitignore (this repo does!) and those are evaluated on the relpath from the .gitignore file, so it's more complicated than just tacking .gitignore lines onto the pants ignore list. For example, we ignore rust build cruft in |
Or maybe the ignore crate handles multiple nested .gitignore files naturally already? |
If I'm reading this documentation correctly, it looks like the ignore crate supports parsing hierarchically-defined |
Just had a user run into a git-ignored directory that contained BUILD files causing them trouble. This would still be a really good thing to do. |
### Problem Cf. issue #5682, we would like pants to pay attention to a top-level .gitignore filee in a pants-controlled repository if the user passes in a `--pants-gitignore` flag. ### Solution Pants already uses the Rust `ignore` crate to handle explicit ignore strings passed in the command line, so we can modify this code to also read `.gitignore` files when we try to do a file access, read the lines contained therein, and use that to decide whether a path should be ignored or not.
#9310 gets us part of the way there. We still need to make pants pay attention to all nested .gitignore files, rather than just a top-level one. |
.gitignore
to --pants-ignore
One of my users hit this when I added a recursive glob on a data directory. Mapping targets took several minutes and we couldn't figure out why. After it completed I asked what the line output of |
I forget why this wasn't easily solved by the ignore crate, but I vaguely remember some difficulty. @gshuflin do you happen to recall? |
It's definitely been a while since I've thought about this - IIRC, the problem was something like, it was difficult to make the code from the rust |
It's not prohibitively hard to glob for the gitignore files from the virtual FS and then construct the ignores by hand, the only blocker is globbing is async and the scheduler is sync. I don't know Rust well enough to bridge that gap |
The alternative is looking the gitignores up dynamically as we try and glob paths, and caching the results. |
There are some comments on the implementing ticket: #9310 (review) The idea of holding onto ignore state as we descend the tree might be related to some of the optimizations mentioned in #14890, but I haven't thought about this particular problem recently. |
I found this while looking for a feature request for supporting recursive gitignore files. I'm running into this problem too now. So... +1 for doing this 😅 |
another +1... |
See #18654 :) Thanks @cognifloyd for talking through the strategy and haha thanks ChatGPT4 for helping to fill out the implementation |
This issue has a lot of history on it, which masks the remaining work to be done. I'm going to close it in favor of #19860, which has a more focused description, and some suggested implementation. |
The
--pants-ignore
option causes pants to ignore files and directories: it uses the same syntax as.gitignore
because it is implemented using the ignore crate. The ignore crate also supports consuming.gitignore
files from disk, but we're currently not using that support.This ticket would deal with adding a pants level option next to
--pants-ignore
that would enable using the.gitignore
file in addition to the explicit patterns in--pants-ignore
. If the.gitignore
file patterns were applied first, this would allow for maximum generality: with that option enabled,--pants-ignore
would be a superset of.gitignore
, but because negation syntax is supported, you could negate patterns in--pants-ignore
if you wanted them ignored by git, but not by pants.--pants-ignore
is declared here:pants/src/python/pants/option/global_options.py
Lines 127 to 131 in 2d4e617
pants/src/rust/engine/fs/src/lib.rs
Lines 388 to 393 in 2d4e617
The text was updated successfully, but these errors were encountered: