> On May 28, 2017, at 11:40 PM, Nick Coghlan <[email protected]> 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
_______________________________________________
Distutils-SIG maillist - [email protected]
https://mail.python.org/mailman/listinfo/distutils-sig
