pyproject.toml detection fails in subdirectories when the file has no [tool.black] section since black 24.2

[meliache]

Describe the bug
Since black release v24.2 black ignores pyproject.toml files without a [tool.black] section. The bug arises because datamodel-codegen uses black's black.find_project_root here, but that now that ignores pyproject.toml files without a [tool.black] section, even if there is a [tool.datamodel-codegen] section, as defined here:

    for directory in (common_base, *common_base.parents):
        if (directory / ".git").exists():
            return directory, ".git directory"

        if (directory / ".hg").is_dir():
            return directory, ".hg directory"

        if (directory / "pyproject.toml").is_file():
            pyproject_toml = _load_toml(directory / "pyproject.toml")
            if "black" in pyproject_toml.get("tool", {}):
                return directory, "pyproject.toml"

At my job I'm working in a monorepo where the python package and the pyproject.toml are in a subdirectory, i.e. with the structure <git root>/<python root>/pyproject.toml>. We use ruff to reformat all generated files, so we didn't have a black config in the pyproject.toml. I noticed that datamodel-codegen could not fild our pyproject.toml. It assumed the project root is the git root, since the pyproject.toml was ignored (see code snippet above).

To Reproduce

• create a git repo where the pyproject.toml is in a subdirectory of the git root and has some [tool.datamodel-codegen] configuration, but no [tool.black] section
• use black 24.2.2 and datamodel-code-generator 0.25.8
• run datamodel-codegen from within the subdirectory with the pyproject.toml on some specification and see if the tool recognizes the config options

Expected behavior
Recognize pyproject.toml if it's in subdirectory and has no [tool.black] section, as long as it has [tool.datamodel-codegen] section.

Version:

• OS: macOS 14.5
• Python version: 3.11.9
• datamodel-code-generator version: 0.25.8

[otonnesen]

My work also ran into this issue recently. I just opened #2242 to address it.