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 The former is the approach that best encourages keeping sdist and wheel file lists in sync, but may fail in cases where one of the other strategies would have worked. Having this option available allows a frontend to prioritise archive consistency at the expense of a reduction in comprehensiveness (i.e. anything it can build will have consistent sdists and wheel archives, but there will be some cases where it will fail to build a wheel where a more permissive frontend would have succeeded). The second pushes the problem onto backends to figure out, and they're frankly in the best position to do so, since they have the most information about what their requirements are, and the greatest ability to *change* their requirements based on the circumstances of use (e.g. by switching from VCS command line tools to Python APIs, and then dynamically requesting the appropriate library based on the available VCS metadata). Some backends won't want to do that, and we're OK with that - it's a "do your best with the information and tools you have available" API, not a "you must get it exactly right every time" API. The final case is then mainly useful in situations where the frontend *knows* it is already working with an unpacked sdist, either because it downloaded it from PyPI, or because it just created it with build_sdist. In those cases, the priority for the backend is to produce a working wheel - whether or not that wheel matches building via the sdist is a lesser concern, since the frontend has indicated that it has either already handled it or else genuinely doesn't care. The exact norms around what's acceptable behaviour for out-of-tree wheel builds (and just how hard backends should try to match the build_sdist -> in-place build_wheel path in that case) is then something that will evolve over time, and I'm OK with that. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia