Adding a non-metadata installer-only `dev-dependencies` table to pyproject.toml

Packaging
10

So I would suggest that the starting point is for Poetry, Hatch, PDM and the others to collaborate on a common interface/API, which could initially be located under [tool.shared]. That doesn’t require any sort of standardisation effort or consensus (beyond all of the tools agreeing). Once that’s established, it would be pretty straightforward to “promote” the data to a top-level standardised key, if people feel that’s worthwhile.

One thought though - handling a key like this is basically trivial in a standalone script:

def install_deps(name):
    with open("pyproject.toml", "rb") as f:
        pyproject = tomli.load(f)
    reqs = pyproject["tool"]["shared"]["dev-dependencies"].get(name)
    if reqs is None:
        raise ValueError(f"Invalid dev dependency name {name}")
    cmd = [sys.executable, "-m", "pip", "install"] + reqs
    subprocess.run(cmd)

Given this, I’d prefer to leave the handling of this feature to “workflow tools”. I don’t think it’s in scope for installers in general (and pip in particular). If someone published the above script for developers who don’t use a high level workflow tool, that would be fine, and would avoid the need for pip to support this.

At some point, I do think that pip needs to make a firm decision on whether it’s a development workflow tool or just an installer[1] - we’re currently in an uncomfortable position of having the same scope debate every time discussions about supporting development workflows comes up. But that’s a separate question, and is something the pip devs can discuss privately.

  1. And as a consequence, is competing with hatch, PDM, etc, or is providing low-level support for them. ↩︎

4 Likes