4 ms·
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
by ubernostrum 8y ago
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).
- StavrosK 8y agoOkay, 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: https://github.com/sdispater/poetry/blob/master/pyproject.toml https://github.com/sdispater/poetry/blob/master/pyproject.to...
- ubernostrum 8y agoAlternative 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.