On Sat, Jul 15, 2017 at 8:50 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 16 July 2017 at 04:33, Donald Stufft <donald@stufft.io> wrote:
All of that is a long winded way of saying I don’t particularly care if the VCS -> wheel -> install path is spelled out *always* doing in-place builds or if we add a build directory to specify between out of place or in place. Having a robust mechanism in place for doing that means we can adjust how things *typically* work without going back to the PEP process and throwing everything away.
+1
The thing I like about the latest draft of the API is that it lets frontends choose freely between three build strategies:
1. build_sdist failing is a fatal error for the overall build 2. ask build_wheel to do its best to emulate a "via sdist" build with what's available 3. ask build_wheel for a wheel without worrying too much about matching the sdist
I guess here you're identifying (2) with "out-of-place builds" and (3) with "in-place builds"? But... that is not what the in-place/out-of-place distinction means in normal usage, it's not the distinction that any of those build systems you were surveying implement, and it's not the distinction specified in the current PEP text. If what we want is a distinction between "please give me a correct wheel" and "please give me a wheel but I don't care if it's broken", then wouldn't it make more sense to have a simple flag saying *that*? And in what case would a frontend ever set this give_me_a_correct_wheel flag to False? I know this sounds like a rhetorical question, but it's not; if a distinction between these is meaningful then there should be some concrete guidance we can give for frontends to choose between them, and for backends to decide which flag setting should behave in which way. Alternatively, would it help to add some language to the PEP saying that build_wheel MUST always produce the same output as sdist->unpack->build_wheel? (I.e., basically making the give_me_a_correct_wheel=True flag the only option, and then if it turns out that sloppy builds have some compelling use case we can add that later.) In particular, I think we could then say that since for distutils/setuptools, MANIFEST.in affects the sdist, then this language means that their build_wheel hook MUST also be sensitive to MANIFEST.in, and therefore it would need to be implemented internally as sdist->unpack->bdist_wheel. (Or if someone's ambitious we could even optimize that internally by skipping the pack/unpack step, which should make Donald happy :-).) And OTOH other backends that don't do this odd MANIFEST.in thing wouldn't have to worry about this. -n -- Nathaniel J. Smith -- https://vorpus.org