Even in your list, there's a problem. I'll describe it first, and then will get to the one I had in mind when I gave my example. It's common that your build r

Even in your list, there's a problem. I'll describe it first, and then will get to the one I had in mind when I gave my example. It's common that your build requirements and your runtime requirements have a big overlap that has to iterate together. Here's a realistic example: NumPy comes with various build helpers that you need at build time, if you are making a native module. So, you need to depend on a particular version of NumPy both during the build and at runtime. In other words, you would want to be able to reference the same package + version in two places. You could say that this is a problem with "specific" package, where the developers didn't care to separate two kinds of requirements... and in some sense you are right... but: there is a value to having build helpers and the rest of the runtime code in the same package. It's simpler. It prevents those using your package from accidentally messing up. Finally, it's NumPy we are talking about, it's not a "specific" package... it's like 50% of the entire Python ecosystem. --- Now, to what I mean in my example. This is taken verbatim from "real Python" site for the lack of a better example: # pyproject.toml [tool.poetry] name = "rp-poetry" version = "0.1.0" description = "" authors = ["Philipp <philipp@realpython.com>"] [tool.poetry.dependencies] python = "^3.9" [tool.poetry.dev-dependencies] pytest = "^5.2" [build-system] requires = ["poetry-core>=1.0.0"] build-backend = "poetry.core.masonry.api" See how "python = ^3.9" is a dependency of Poetry? But what if I also want to make my project build with setuptools? Setuptools also depends on Python... where would I put that now? Not under [tool.setuptools.dependencies]? What do you think?