Project root detection logic leads to configuration duplication in some circumstances

[layday]

Currently, μfmt appears to look for tool configuration in pyproject.toml files relative to the file under format, selecting the nearest ancestor. In a monorepo, or in a repo with a main package and several sub-packages, this would require duplicating black's and μsort's (and μfmt's) config in each individual package's pyproject.toml. Some alternatives I can think of are:

• Adding a command-line option for the project root
• Taking the project root to be the cwd - this is a departure from how μfmt works right now so I assume you won't want to do this
• De-prioritising pyproject.toml without a [tool.black] or [tool.usort] section, continue looking up the tree - if people do want to override the config from an outer folder they'll need to add a [tool.x] section in their pyproject.toml which is not the least bit intuitive
• Do nothing :)

Thanks for μfmt!

[amyreese]

The current behavior is specifically designed with a monorepo in mind, though more from the perspective of embedding third party/OSS packages into a larger repo, where stopping at the nearest pyproject.toml ensures that formatting a file "internally" will have the same behavior as formatting the file externally on CI or a standalone checkout, regardless of whether the monorepo uses custom formatting options for everything outside of the third party imports. Granted, that behavior is then suboptimal for projects that contain multiple related packages, each with their own subdirectory and pyproject.toml.

The former use case is one that I have a vested interest in maintaining; the latter is one that I'm sympathetic to, but haven't personally run into, and I'm not really sure how to find a good compromise between these two use cases, and their needs seem somewhat opposed. I'm open to ideas though.

That said, I think that adding a --root option would be a simple step forward, and the cwd case could be handled by passing --root=..