I tend to discourage configurations that might change behaviour in ALE specifically in a committed project file.

You're right — our current approach to determining the Python project root is admittedly a bit hacky, and it's true that we already rely on committed project files for this behavior. Right now, we walk up from "the file" until we hit a known config file, which works well for most projects. I understand the logic behind it — it's a simple heuristic that covers a lot of cases.

That said, some projects can be structured in less conventional ways, and this method can be too optimistic. Personally, I’d like to have some mechanism to override or customize this behavior when needed.

Do you have any thoughts on how we could allow users to explicitly set or override the Python project root?

Let's change the behavior actually to prefer the value of theale_root setting that already exists. Ifale_root is set, always prefer that over everything else and skip all of the directory searching behaviour. It'll be faster than scanning the filesystem, and it will be pretty consistent. Have a look at:h ale_root and uses in the codebase already. I'd say:

1. Renameale#lsp_linter#FindProjectRoot toale#linter#GetRoot and put it inlinter.vim at the bottom of the file
2. Probably replacereturn ale#util#GetFunction(a:linter.project_root_callback)(a:buffer) in that function with justreturn '' as I think that's a bug that never gets triggered in code paths for LSP linters.
3. Call the newale#linter#GetRoot function first inale#python#FindProjectRoot
4. Add more tests to cover the changes/
5. Update comments in code and documentation everywhere to explain the new behaviour.

Theoretically a breaking change, but a change for the better.

For fun I'll set OpenAI Codex to the task and see how well it does...

@mangin Okay, so Codex did avery good job actually.#4993

You can rip off this commit and tweak it a bit.

I'll close this one. See the draft of the other option I proposed here.