Took a peek at the warehouse source code to try to understand its sdist requirements, it appears to be less strict than I thought. Probably missed something but it looks like warehouse currently requires a .zip sdist to contain PKG-INFO one level deep but doesn't care about the contents of .tar.gz files. pip of course still expects to be able to execute setup.py egg_info but it doesn't look like it cares about PKG-INFO or anything else.
On Tue, Jun 13, 2017 at 5:45 AM Thomas Kluyver <tho...@kluyver.me.uk> wrote: > 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 >
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
