> On May 11, 2016, at 9:08 PM, Brett Cannon <br...@python.org> wrote: > > > > On Wed, 11 May 2016 at 16:01 Nathaniel Smith <n...@pobox.com > <mailto:n...@pobox.com>> wrote: > On Wed, May 11, 2016 at 11:32 AM, Brett Cannon <br...@python.org > <mailto:br...@python.org>> wrote: > [...] > > the file is for the project, not just the package(s) the project > > contains ("package" is an overloaded term and I don't want to contribute to > > that with the filename; I can live with the build details being in relation > > to a package in the project and thus named [package], but other things that > > may end up in this file might not relate to any package in the project). > > We went back and forth on the overloaded "package" name a bit while > drafting too, and eventually just gave up and went ahead because it's > not that important. > > To me this feels similar to situations I've encountered in the past, > where I've spent a bunch of time debating between two things, and it > turned out that the reason we couldn't agree was because both > proposals were wrong and a third solution was much better :-). > > I still don't think the [package] name part is worth arguing about > much, but throwing this out there in case it turns out to be that > "third way" that suddenly makes everyone go "a-ha!": > > If you think about it, really the stuff in [package.build-system] is > there to tell pip how to run the build system. It's associated with > building the project/package, sure, but that's not what makes it > special -- everything that goes in this file will be associated with > building or developing the project/package: [tool.flit], > [tool.coverage], [tool.pytest], [tool.tox], whatever. The build-system > stuff could easily and comfortably have gone into > [tool.pip.build-system] instead... *except* that we don't want it to > be specific to pip, we want it to be a piece of shared/common > configuration that's defined by a shared process (PEPs) and used by > *multiple* tools. That's why it doesn't belong in [tool.pip]. > > Or another way to put it, contrasting [tool.*] versus [package.*] is > kinda weird, because those categories aren't actually contradictory -- > it's like having categories [red] versus [square]. > > So, proposal: maybe we should rename the [package] namespace to > something that reflects what distinguishes it from [tool], like: > > [standard.build-system] > > or > > [common.build-system] > > or > > [shared.build-system] > > > or > > [base.build-system] > > or > > [super.build-system] > > I'm +1 on base, super, or common, +0 on standard, -0 on shared. > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > <mailto:Distutils-SIG@python.org> > https://mail.python.org/mailman/listinfo/distutils-sig > <https://mail.python.org/mailman/listinfo/distutils-sig>
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.
The value of the [tool] namespace isn't that it doesn't make sense for a [flit]
and a [package] to be at the same level, but rather that we have no idea what
keys people might use there (and indeed, `package` is taken on PyPI) but that
it allows us to separate the wild west of "anything goes" from the strictly
defined the rest of the file.
IOW, the reason to omit the [standard] namespace and the reason to include the
[tool] namespace is practicality being purity and designing this file first for
humans to edit it, and only second for machines to access it and some sort of
semantic purity a distant third.
-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
