ruff.toml has dependency on extant pyproject.toml

[jaraco]

In #119, we added a new extend = "pyproject.toml" directive in order to work-around the ruff limitation that it cannot infer a target Python version unless the pyproject.toml is included.

Today, I learned that causes other problems downstream when I attempt to use that ruff.toml in other contexts, such as in the coherent system. In that system, ruff.toml isn't managed per-project, but is managed by the system and is shared across projects. In my environments, I'm relying on the presence of a copy of the skeleton's ruff.toml in ~ so that it applies to coherent projects.

However, with the introduction of this new setting, those projects are no longer capable of running ruff, because the extend = "pyproject.toml" fails when there is no pyproject.toml:

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

This is yet another case where the astral-sh/ruff#10299 is not honoring the user's intentions, but it wouldn't be a problem if ruff could rely on standards metadata instead of expecting to find the metadata in a particular file.

[jaraco]

Another degree of workaround may be possible here - to have a ruff.toml in the skeleton that extends a common ruff toml config and pyproject.toml... and then the coherent system could use the common ruff toml config. But, yuck!