3 ms·
pyproject.toml isn't another way to specify dependencies for Python code. The long version of why it exists: Historically, a Python package has been defined b
by ubernostrum 8y ago
pyproject.toml isn't another way to specify dependencies for Python code.
The long version of why it exists:
Historically, a Python package has been defined by the existence of the setup.py file. Executing this file with various command-line arguments is how packaging tasks are carried out: 'setup.py install' installs the package, 'setup.py sdist' builds a source distribution (.tar.gz) suitable for uploading to a package repository, etc., etc.
But this workflow has dependencies! Most packages will only depend on setuptools (which supplies the setup() function) and wheel (which supports building binary packages), so the packaging tooling assumes the presence of setuptools and wheel and you never have to specify them as explicit dependencies (in the old old days, setuptools used a drive-by installer file bundled into the package so people who didn't have setuptools could still install setuptools-based packages; nowadays, pip supplies it automatically).
But what if you have a workflow that requires something else? What if you use an alternative package manager, or package build tool, or really anything that isn't setuptools or wheel? How do you specify the toolchain you need to work with your package?
That is the thing pyproject.toml solves. Since it's not an executable Python file, it can't get stuck in a chicken-and-egg problem ("execute setup.py to find out what you need to execute setup.py"), and it can specify the necessary build system for a package in a standardized way.
- StavrosK 8y agoYes, I understand the purpose, but the result is that it replaces any previous way of specifying dependencies. It's great that it exists, but it's frustrating that it was developed right when the new thing for specifying dependencies (Pipfile) was starting to become popular.
- ubernostrum 8y agoIf 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.
- StavrosK 8y agoIf 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.
- ubernostrum 8y agoSuppose 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.