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

**URL:** <https://discuss.python.org/t/adding-a-non-metadata-installer-only-dev-dependencies-table-to-pyproject-toml/20106>\
**Category:** Packaging\
**Created:** [October 19, 2022, 2:18am UTC](https://discuss.python.org/t/adding-a-non-metadata-installer-only-dev-dependencies-table-to-pyproject-toml/20106 "2022-10-19T02:18:29Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\
**Post date:** [October 19, 2022, 12:07pm UTC](https://discuss.python.org/t/adding-a-non-metadata-installer-only-dev-dependencies-table-to-pyproject-toml/20106/10 "2022-10-19T12:07:29Z")

</div>

> [@pradyunsg](#):
>
> And, yes, installers such as pip would be expected to provide interfaces to install these requirements. The fact that Poetry, Hatch, PDM and others have implemented these mechanisms is (IMO) a clear indicator that this is a useful thing to have in user workflows.

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:

```python
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.

---

_[View the full topic](https://discuss.python.org/t/adding-a-non-metadata-installer-only-dev-dependencies-table-to-pyproject-toml/20106)._