If you think it's another "thing for specifying dependencies" in the category of the pipenv Pipfile, you have not understood the purpose of pyproject.toml.
If you think that's what I think, you haven't understood my comment. Again, I'm saying that I don't want to migrate to yet another format so soon, even if it does much more than just specify dependencies.
Suppose you are developing something which needs to make HTTP requests. So you have a dependency on the requests library.
pyproject.toml is not the place where you declare that dependency. This is why I am pushing back on you, because your comments all very very very strongly imply that you think pyproject.toml is a place where you would declare that dependency.
pyproject.toml is where you'd declare that you're using an alternate build/packaging toolchain. You would then use whatever mechanism that toolchain provides for specifying your dependencies (in the case of the default setuptools build/packaging toolchain: install_requires in setup.py).
Okay, I see what you mean now. I was confused because Poetry declares dependencies in the pyproject.toml, but looking at the actual file, it does it in a Poetry-specific section, so it's not compatible with any of the other tools:
Alternative packaging toolchains can use pyproject.toml that way; it's an extensible file.
But you've caught on to the key thing, which is that neither they, nor the default setuptools-based toolchain, have to do that. The pyproject.toml file exists to solve the chicken-and-egg problem of specifying that you use an alternative toolchain, when figuring that out might otherwise be dependent on your preferred toolchain already being present and configured.
