better error message when an inherited config path doesn't exist

[purajit]

Currently, if a ruff config extends a non-existent file via extend = , you
get an incomplete error message that could be very misleading (I spent quite some
time wondering why ruff was trying to load a pyproject I deleted, and found out
what was going on after building a local ruff with tons of prints).

Previously:

ruff failed
  Cause: Failed to read <path>/pyproject.toml
  Cause: No such file or directory (os error 2)

Now:

ruff failed
  Cause: Failed to load path <path>/pyproject.toml inherited by <path>/subpath/pyproject.toml
  Cause: Failed to read <path>/pyproject.toml
  Cause: No such file or directory (os error 2)

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

[MichaReiser]

I find the wording here slightly confusing. It suggests that the path is inherited where it is the configuration.

I also think we should track the entire stack because the message is now inprecise in case there's a inheritance chain like a -> b -> c because the message only mentions that b extends c without mentioning a.

There are also other paths where this method returns an error (e.g. bail) where the inheritance chain will be missing.

That's why I suggest making the following changes:

1. Store the path in the stack so that we get the entire inheritance chain instead of just the last
2. move the body of the while loop into a function (or lambda) to ensure we attach the context to all errors returned in the while loop
3. Change the error to Failed to load configuration {path}: error ({chain}) where chain is only shown if the stack isn't empty (and it shows a -> b -> c)

[purajit]

Hmm in the case of a -> b -> c, if c doesn't exist, why do we care about a? Fixing the extends clause in b should be enough, and providing the full chain might be confusing vs just providing the file that caused the error, and which file tried to extend it. The meaning of the direction of the arrow could be confusing too.

However, down to make the changes and my opinion isn't too strong here. I'll take a stab tomorrow.

[MichaReiser]

That makes sense. I understood that the main motivation is that it's hard to understand why a file gets imported (how does Ruff end up with that given path and where can I change it). That's why I thought it's helpful if we show the entire inheritance chain over letting users guess how Ruff ended uploading that file, but it might go beyond of what the goal of this PR is.

I'm open to use anything other than -> if you consider its meaning ambigious. We could also use aextendsb`

[MichaReiser]

Nice, this is a great improvement. I've some suggestions on how we can improve the message further. It would probably also be good to add a CLI test for it, similar to what we have here