
On 4 July 2017 at 12:46, Nathaniel Smith <njs@pobox.com> wrote:
if hasattr(os, "symlink"): def prepare_build_files(tmp_dir): os.symlink(os.getpwd(), tmp_dir)
and now pip will do in-place builds. (Except on Windows, of course; Windows users get screwed as usual, but from scipy's perspective that's pip's fault.)
scipy shouldn't be relying on pip as their frontend for local development builds (except via pip -e), and if frontends see backends actively subverting their build policies, they'll be well within their rights to blacklist those backends (or, more likely, push them into a chroot or container, rather than just using a subprocess with normal user level access to the host filesystem). However, Donald's persuaded me that the cases where: 1. build_sdist will be called (i.e. not starting with a known sdist); and 2. build_sdist will throw an exception are going to be sufficiently rare that we can drop the input preparation hook, and instead just let the build fail in such cases (the conclusion of the previous round of discussions suggested we weren't going to be OK with that, so I'm happy to change my view based on the updated info). Going down that path also still leaves frontends with the option of looking for a pre-existing PKG-INFO file when handed an arbitrary directory and taking that into account when deciding which build strategy they want to use (in-tree or out-of-tree), and which copying strategy they use in the out-of-tree build case. Cheers, Nick. P.S. `build_sdist` should still indicate failure by throwing an exception, not by returning a non-string result. However, frontends should also fail the build when a backend doesn't adhere to the specification (so returning NotImplemented would technically be an alternative way to trigger a build failure, just not a recommended one) -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia