On Tue, Jun 13, 2017, at 02:27 AM, Nick Coghlan wrote: > Despite being the one to originally propose standardisation on passing > directory paths around, I'm starting to lean back towards this > approach. > > My rationale for this doesn't really have a lot to do with topics > we've discussed so far, and instead asks the question: what would work > best for an installation frontend that wanted to keep the actual build > tools off the system doing the installation, while still allowing for > transparent "from sdist" installations?
I think that we're discovering a variety of reasons why an unpacked distribution may not be clearly preferable to an archive. In the absence of a clear benefit, I think it's advantageous to say that the archive is the canonical interchange format which different tools produce and consume. This is more compelling for wheels than for sdists, since the wheel format is more precisely specified, but it seems more internally consistent to say that they both build archives. I've updated the PR to specify zip archives for build_wheel and .tar.gz archives for build_sdist. >> 2) Specify that the wheel generation hook, metadata hook, and sdist >> hook return the name of path that they created as a unicode string. >> Rationale: fixes a point of ambiguity in the current spec. > > And still leaves the door open to supporting multiple wheels in the > future by returning a list instead of string. This makes sense to me, and I've added that to the PR. I have currently specified that they should return only the basename of the file/directory they create, not the full path. I don't think there's any particular reason to prefer one or the other, but it needs to be specified. Does anyone think there's a concrete reason they should be full paths? Finally, I noticed while updating the PEP that there's a section showing how simple a PEP 517 backend can be, with a tiny working example. Following our discussions, that example is incomplete (it's missing at least the sdist hook). Do we want to: 1. Make the example complete again, which would make it much less simple. 2. Remove the whole section about how easy it is to implement a backend (it's not a very convincing example anyway, because it requires the user to manually do most of the work in preparing a wheel). (3. Try to actually make it simple to implement a backend ;-) Thomas _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
