[Distutils] Provisionally accepting PEP 517's declarative build system interface

[Donald Stufft]

> On May 28, 2017, at 11:40 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> Hi folks,
> 
> I am hereby provisionally accepting PEP 517 as our CLI independent
> interface for build backends, allowing interested parties to move
> forward with implementing it as part of pip and other tools.
> 
> As with other provisionally accepted PyPA interoperability
> specifications, it won't be considered completely settled until it has
> been implemented and released in pip and we have at least one
> iteration of end user feedback.
> 
> Thanks to Nathaniel & Thomas for their work on the PEP, and to
> everyone that participated in the related discussions!
> 


Bleh, I had it on my stack to respond to PEP 517, but life has been super hectic so I hadn’t gotten around to it.

Here are a few thoughts FWIW:

1. Using the {package-name}-{package-version}.dist-info in the get_wheel_metadata() metadata is a mistake I think. In pip currently we have a bug we have not yet been able to track down because there is nothing systematically preventing both foobar-1.0.dist-info and foobar-2.0.distinfo from existing side by side in a build directory (or inside a wheel for that matter). Thus I think this naming scheme is a nuisance and we shouldn’t propagate it any further. I would just use something like DIST-INFO/ which will completely side step this issue. The only reason I can think of to use the current scheme is to make it easier to shutil.copytree it into the wheel, but handling that case is trivial.

2. As I mentioned in previous discussions on this, I think that this interface *needs* some mechanism to ask it to build a sdist. Ideally this would either fail or recreate the sdist when being run from something that is already an sdist. In pip when we’re doing ``pip install .`` we currently copy tree the entire thing into a temporary directory, and we run the build out of there. For a variety of reasons we’re going to keep build isolation, but the current mechanism is painful because it also grabs things like .tox, .git, etc. At one point we tried to simply filter those out but it broke some packages expectations. The planned (which is on my long list of things to do…) mechanism to fix this is to create a sdist from a ``.`` and then install from that (building an intermediate wheel as well). This also solves another class of bugs that people run into where ``pip install .`` and ``python setup.py sdist && pip install dist/*`` give different results. As written, this PEP prevents that from happening (and thus, when I implement it, I’ll only be able to implement it for old style sdists, and will need to tell people to continue to use old style if they don’t want pip to grab random directories from ``.``).


Other than that, it looks fine, and #2 is the one that I think is going to be the bigger issue in pip.

—
Donald Stufft



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20170529/f7f7a276/attachment.html>