Repo-specific configuration

[greaber]

I love the capabilities of the ripgrep program, but it has a bunch of defaults, particularly around what files it scans and doesn't scan, that are rarely what I want, and there is no simple way to configure good per-project defaults because using a configuration file requires setting a special environment variable. Could ripgrep just always check in the current directory for a standard config file like .rigpgreprc.proj that I could just add to the root of each project? Or, if this would break things for some people, what about distributing a second binary or something that would have this behavior?

[BurntSushi]

This was request here and possibly in other places. While the conversation there got somewhat side-tracked by discussion of dotconfig files littering $HOME, that's only one problem with the proposal. The bigger problem, and the principal reason why I will never add this functionality to ripgrep, is that I perceive it to be wildly confusing from a user experience perspective.

Just imagine that you have ripgrep configured to behave how you want. Then you go and clone a repository to search it. Now all of a sudden, ripgrep is behaving completely differently! Maybe it's using different colors. Or it's setting the case insensitive flag. Or one of a number of other unexpected or whacky things.

Moreover, you also have the problem of figuring out how to deal with cases where ripgrep searches many directory trees, each with their own configuration. Should ripgrep respect each of them for a specific directory? That would basically require ripgrep to possibly re-initialize itself for every directory containing a config file (e.g., re-compiling regexes when options that influence regex construction are provided). Or should ripgrep only respect such config files if they are in the directory in which ripgrep runs? What if you do rg ./path/to/project?

There's just an absolutely massive mine field of potential user experience issues.

You mention that this could be circumvented by introducing a second binary that does this. But that only helps the first problem above. It doesn't answer any of the other user experience problems. And having a second binary for this just seems totally confusing to me. Besides, if that's something acceptable to you, then you have your answer: you can write a very simple wrapper script that sets RIPGREP_CONFIG_PATH to whatever configuration file you want, and then invokes rg. That way it's opt-in and does exactly what you want.

but it has a bunch of defaults, particularly around what files it scans and doesn't scan, that are rarely what I want

I think this use case could be more detailed, because as written, this doesn't acknowledge the existence of .ignore or .rgignore, which exist for precisely what you describe here. And those files do specifically allow for project specific filtering (or not filtering). Now there are plenty of options in ripgrep you might be talking about. Maybe for some projects you want -uuu to be set, for example. In which case, yeah, ripgrep's existing ignore-file functionality probably isn't sufficient for that. If you really need project specific configuration, then you'll want to go with a wrapper script or something that sets RIPGREP_CONFIG_PATH.