Support a way to ignore (potentially user-specific) IDE files in glob expressions
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 16h
- Merged PRs (30d)
- 72
Description
### Description of the feature request:
Allow to specify list of patterns ignored by ALL glob() expressions in the project.
### Which category does this issue belong to?
Loading API
### What underlying problem are you trying to solve with this feature?
#### Details of the feature request
Let's say I am releasing the code of my project with the following BUILD file:
```
filegroup(
srcs = glob(
["**"],
exclude = [
"BUILD.bazel",
"**/*.bzl",
".git/**",
],
)
)
```
However, when a user of our project uses an IDE, the IDE may generate files that are captured by the IDE. Different people use different IDEs, so it is hard for us to exclude all files potentially generated by IDEs. For example, this may include `.swp` files generated by Vim, or [ctag files generated by code indexing tools](http://r.android.com/2911882).
Hence, I am proposing to add a feature that allows a user to specify a list of files generated by their IDE as a local configuration. This may be a command line option that a user place in their `$HOME/.bazelrc` below , or some `$HOME/.bazelglobignore` for example. (The path here is just for illustration purposes. Please change it to wherever makes sense.)
As a project owner, it may also be useful for me to add a `/.bazelglobignore` file that excludes files generated by commonly known IDEs, or add it to `/.bazelrc`. (The path here is just for illustration purposes. Please change it to wherever makes sense.)
#### Alternatives
**Why not just add it to glob(exclude = [])?**
* It is not future proof. If someone add a glob() somewhere else in the project in the future, and forgets to add the common exclude list, we have a regression.
* It is not user-specific. If a user uses an exotic IDE not known by us, they have to submit a patch to us to get their IDEs fixed. With this feature, the user just needs to add their IDE-generated files to their `$HOME/.bazelglobignore`.
**Why not use an allow list instead of a deny list?**
One may argue that the `glob(["**"])` is the source of evil. Indeed, the issue is resolved if a more precise list of patterns are provided, so that IDE-generated files are never globbed.
However, it is hard for us to switch to an allowlist for our project ([Build Android kernel with Bazel](https://android.googlesource.com/kernel/build/+/refs/heads/main/kleaf/docs/kleaf.md)), because the list of all files from upstream Linux kernel changes as the source code evolves.
### Which operating system are you running Bazel on?
Linux
### What is the output of `bazel info release`?
release 7.3.0
### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.
_No response_
### What's the output of `git remote get-url origin; git rev-parse HEAD` ?
_No response_
### Have you found anything relevant by searching the web?
There is `.bazelignore` https://bazel.build/run/bazelrc#bazel-behavior-files that serves a similar purpose.
But it is for directories, not for individual files.
### Any other information, logs, or outputs that you want to share?
We added ctag files as a temporary workaround: http://r.android.com/2911882. This issue comes up again when an internal developer using Vim gets intermittent build breakages/success builds due to .swp files generated by Vim.
Contributor guide
Research direction
Start with the Loading API's glob() entry point and review the existing .bazelignore behavior, then compare the BUILD file and .bazelrc examples described here. Done means a decided configuration mechanism applies user- and workspace-level file patterns to every glob() expression without repeated exclude entries, with the behavior documented and verified.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- build-system
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100