The bug reported expected distutils to create an __init__.py file for a
project using only C extension modules. IMO, how Python imports
packages and submodules is well documented, and it’s never suggested
that distutils might create an __init__.py file, so I’m adding this
clarification to the packaging docs but won’t backport unless other
people tell me they shared the same wrong expectation.
Thanks to Mike Hoy for his help with the patch.
The right-hand part in [extension: foo] is now used as the name of the
extension module. (I changed the separator from = to : and allowed
whitespace to make the sections look nicer.)
Packaging uses the shutil.make_archive function copied from distutils,
which does not support compress. There is no test to check that
“bdist --format whatever” works, so this slipped by.
In the install and library docs, I changed the text to refer to
packaging instead of distutils. I also checked that the documented
paths correctly reflect what’s really defined in sysconfig; the main
difference with paths defined in distutils.install is that include
directories don’t end with the distribution name anymore (i.e. distutils
uses include/python3.3/spam, sysconfig include/python3.3), I have no
idea why.
I chose “setupcfg” as prefix instead of “packaging-setupcfg” because the scope
of the spec is not limited to packaging: it’s intended as a language-agnostic
document for packaging tools developers as well as Python authors.
I tried shortening the sidebar ToC with the tocdepth option instead, but it has
a bug which caused all headings with a level deeper than the tocdepth value to
all have the same section number, which was a usability regression rather than
in improvement.