ignore .ale-not-project-root directories during determine Python Proj…

[mangin]

…ect directory
Here’s a clearer and more polished version of your GitHub PR description, with improved grammar, clarity, and structure:

---

Problem

In our monorepo, we have a structure like this:

mono_repo/project_1/setup.cfg
...
mono_repo/project_N/setup.cfg
mono_repo/setup.cfg

When using ALE (Asynchronous Lint Engine) for linting, it automatically determines the Python project root by locating the first directory that contains a Python config file (e.g., setup.cfg, pyproject.toml, etc.).

However, in our setup, this behavior can be problematic. For example, ALE may incorrectly treat the top-level mono_repo/project_*/setup.cfg as the root, instead of one of the nested mono_repo directory. This prevents us from applying linter rules defined at the project level.

Proposed Solution

To address this, I propose introducing a marker file named .ale-not-project-root. When ALE encounters this file, it will skip that directory as a potential Python project root and continue "searching deeper."

Example Use Case

mono_repo/
mono_repo/setup.cfg
mono_repo/project_1/.ale-not-project-root
mono_repo/project_1/setup.cfg
mono_repo/project_2/.ale-not-project-root
mono_repo/project_2/setup.cfg

With this marker, ALE will skip mono_repo/project_1 and mono_repo/project_2 and use the setup.cfg from the root.

Feedback

Does this approach sound reasonable? Happy to discuss alternatives or improvements.

[w0rp]

This is a bit too hacky. I've prefer tweaking this a bit better to match project roots, possibly removing some of the old files we used to test for. I removed pytest.ini this morning, for example.

[w0rp]

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

[mangin]

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?

[w0rp]

Let's change the behavior actually to prefer the value of the ale_root setting that already exists. If ale_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. Rename ale#lsp_linter#FindProjectRoot to ale#linter#GetRoot and put it in linter.vim at the bottom of the file
2. Probably replace return ale#util#GetFunction(a:linter.project_root_callback)(a:buffer) in that function with just return '' as I think that's a bug that never gets triggered in code paths for LSP linters.
3. Call the new ale#linter#GetRoot function first in ale#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...

[w0rp]

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

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

[w0rp]

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