[Distutils] comparison of configuration languages

[Brett Cannon]

On Mon, 9 May 2016 at 06:29 Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 9 May 2016 at 01:43, Donald Stufft <donald at 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.
>

I'm not going to touch the concept of development dependencies to keep the
PEP focused.

But one thing this discussion does bring up is everyone is assuming there
is simply going to be a [dependencies] section to the configuration file
where build, development, and/or installation dependencies will eventually
end up.

My current plan for the PEP is to not do that. Instead, I'm going to have a
[build] section that will have a `dependencies` field. My thinking is that
we don't need to have any end-users who choose to look at this file care
about anything related to building or developing a project. Plus if we
expose any details about the Future Awesome Build API (aka the FAB API ;)
then it should probably be kept near all of the other build-related
details, including the dependencies for building instead of inherently
spanning multiple sections (yes, tools will quite possibly have their own
section, but we can try to keep it to [build] and e.g. [tools.setuptools]
and not [dependencies], [build], and [tools.setuptools]).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160509/254b84bd/attachment.html>