> I *do* care about telling backends we don't want "different results from those that would be obtained by exporting an sdist first".
I completely agree with this statement, but I don't believe that it can or should be accomplished with this parameter. Let me just quote the process that I proposed: > Proposed process: - Frontend copies source tree to temporary directory - Frontend invokes build-sdist to build an sdist - Frontend extracts sdist to new temporary directory - Frontend reloads backend from sdist directory and invokes build-wheel This process makes the most sense to me because there will be a limited number of frontends AND the frontends will enforce correctness. I don't think we should be too cautious about burdening the frontends will more responsibility, because it will only be implemented once or twice. And to clarify, the build_sdist is required. 2017-08-24 9:51 GMT-05:00 Paul Moore <[email protected]>: > On 24 August 2017 at 15:26, Thomas Kluyver <[email protected]> wrote: > > I particularly want to hear from Nick, Daniel, Donald and Paul on their > > understanding of the build_directory parameter. There were reasons why it > > got added, and even if those reasons no longer seem so convincing to me, > > it's only going to be removed again if we can reach a consensus on > working > > without it. > > OK. I've not had much time recently (RL issues) and so my apologies if > I've forgotten context here. But my feelings are: > > 1. I've been pretty much persuaded that including features in the > interface to defend against badly written backends is not worthwhile. > (I still worry that it may be hard to provide good error reporting for > backend errors, but that's a lesser issue). > 2. I'm not completely clear on how pip's implementation will work - I > think the intention is to always build a sdist and build a wheel from > that, unless the backend reports it can't build a sdist, in which case > we ask it to build a wheel directly. > 3. I'm not particularly comfortable with backends saying that they can > only produce a wheel and not a sdist, but accept that might have to be > a reality in some cases. I would be *really* bothered by a backend > that wasn't even willing to accept that sdist->wheel and direct wheel > builds should be equivalent - but I don't know if that's something > that is likely to happen (we can of course state that expectation in > the PEP). The PEP seems to think this is possible, though[1] (see my > next point). > 4. The point of all this is that the definition of build_directory > says "If build_directory is None, the backend may do an 'in place' > build which modifies the source directory and may produce different > results from those that would be obtained by exporting an sdist > first". That's the bit that bothers me a lot - if we lose > build_directory, we lose the option for pip to request that a backend > produce a wheel "equivalent to producing an sdist first". And that > capability is something I think pip should require[2]. I don't > particularly care who specifies the actual directory (as per your > comment, I thought someone else wanted this, for caching or something) > but I *do* care about telling backends we don't want "different > results from those that would be obtained by exporting an sdist > first". > > Paul > > [1] The only example I can think of is flit where the user doesn't > have git installed. But then I'd expect that a wheel generated > directly in that case would be the same as if the user installed git > then did sdist->wheel, so I'd still consider that to be maintaining > the invariant I care about. > [2] I'm not likely to be the one implementing pip's PEP 517 support, > so I could be overridden on this, of course. > _______________________________________________ > Distutils-SIG maillist - [email protected] > https://mail.python.org/mailman/listinfo/distutils-sig >
_______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
