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.