On 9 May 2016 at 01:43, Donald Stufft <donald@stufft.io> wrote:
Overall, my suggestion here would be to have a file called ``pymeta.toml`` (or ``meta.toml``)
pymeta.toml would be fine by me. I don't really buy the "collision with Debian build tool" argument against "pybuild" (if I did, I'd be objecting to "pymeta" colliding with an existing PyPI package), so it's mainly the fact the metadata in this file covers more than just building has soured me on it.
and have it look like::
[dependencies] build = [ "setuptools", "wheel>=1.0", ]
If at some point we decide we need to add a bootstrap_requires (and then the ability to add dynamic build requirements) we can do that by just saying that if you plan on having dynamic build requirements, you need to omit the build key under the [dependencies] section.
Looking at my previous ideas for semantic dependencies in PEP 426, what if we start in the near term by defining development requirements? That can then be used to hold arbitrary development dependencies (metadata generation, sdist creation, test execution, wheel build, docs build, etc), everything that you need to work on, build, and test the software, but don't need if you just want to run the published releases. We may later decide that we want to break that down and separate out specific requirements for sdist creation and for wheel creation, but we can handle that by saying that if there's no more specific dependency definition for an operation, then the tools will fall back to pre-installing all the listed development dependencies. That is, someone might write: [dependencies] develop = [ "setuptools", "wheel>=1.0", "sphinx", "pytest", ] And it would be useful not only for running setup.py commands, but setting up their local dev environment in general. (Having docs build and test dependencies listed would be entirely acceptable for the RPM spec autogeneration case, since we just have the BuildRequires/Requires split at the RPM level, and often need the docs dependency to generate man pages, and the test dependencies to run the unit tests in the %check scriptlet) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia