[Distutils] PEP for specifying build dependencies

[Donald Stufft]

> On May 11, 2016, at 9:45 PM, Nathaniel Smith <njs at pobox.com> wrote:
> 
> On May 11, 2016 6:33 PM, "Donald Stufft" <donald at stufft.io <mailto:donald at stufft.io>> wrote:
> >
> [...]
> >
> > I don't like any of these options nearly as much as [package] TBH. I don’t
> > think that base, super, common, standard, or shared are any less ambiguous than
> > package (in fact I think they are _more_ ambigious).
> >
> >
> > I don't really think of it as package vs tool, I think of it as an implicit
> > <standard stuff> vs an explicit <third party stuff>. I think it makes the file
> > uglier to have the <standard stuff> explicit, particularly since I think the
> > example should really be something like:
> >
> >     [standard.package.build-system]
> >     requires = ["setuptools", "wheel"]
> >
> >     [tool.flake8]
> >     ...
> >
> > Because the value of the [package] namespace isn't that it separates us from
> > the [tool] namespace (we could get that easily without it), but that it
> > separates us from *other*, non packaging related but "standard" stuff that
> > might be added in the future.
> 
> Can you give an example of something that would go in your hypothetical implicit a pyproject.tml [standard] section, but that would not be related to configuring that project's package/packages and thus go into [package]? Partly asking because I'm not sure what the difference is between a "project" and a "package", partly because if we can articulate a clear guideline then that'd be useful for the future.
> 
> -n
> 


This is somewhat of a contrived example because I’m not sure how useful it would be to have a standard representation of it, but one possible example is PEP8 (the actual PEP not the tool on PyPI) linters and what rules they follow that would allow people to use arbitrary linters against a code base (which may or may not be a “package” in the PyPI/pip/PyPA sense) but is just a chunk of code sitting in a directory.

A less contrived answer is that I simply don’t know, but it feels like the “cost” of introducing the [package] top level is pretty low (a total of 8 additional characters per table) and in my head it has some meaning (this is the stuff for a Python distributable package, that you could, but maybe don’t, ship on PyPI and install with pip). I view the “project” as a superset of that, where part of configuring a “project” may include configuring the package side of things (assuming it is even a package and it isn’t just some arbitrary code in a dir) but might also include other things.

On the other hand, I feel like `[standard]` or whatever isn’t really meaningful as anything other than “the stuff that isn’t in [tool]”, which makes me feel like adding it in is mostly a purity thing and the cost (a total of 9 extra characters per table) doesn’t seem worth it since any human will be able to trivially identify the set of things which are not in the tool namespace, and computers can also do that pretty easily (although slightly clumsily).

Now, you could argue that the [package] keyword is superfluous and in reality it’s highly unlikely that we ever get anything major that would ever sit as a sibling to it (besides tool) and thus it doesn’t make sense to pay the cost of those extra 8 characters when it is probably going to be the only non-tool value ever. Personally I think hedging our bets and leaving the door open for that possibility is a nice thing to do when the cost is so low. However, I don’t think it’d be unreasonable or silly to make the other trade off and just say that having it isn’t valuable and just stick [build-system] at the top level along with [tool.*] and say that if we ever come up with something that is not related to a package (in the PyPA sense) that it really won’t be that big of a deal to just have it live beside stuff like [build-system].

So I think we should either have:

[package.build-system]
requires = [“setuptools”, “wheel”]

[tool.flake8]
…

OR

[build-system]
requires = [“setuptools”, “wheel”]

[tool.flake8]
…

but I don’t think trying to make the parsed tree fit some “correct” hierarchy of data types when you consider the [tool] section (which really only exists to prevent collisions, otherwise we’d just let people stick [flake8] etc at the top level) is worth it.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160511/f7011d3b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160511/f7011d3b/attachment.sig>