On Thu, Jun 15, 2017 at 6:12 AM, Thomas Kluyver <thomas@kluyver.me.uk> wrote:
Yes, it's PEP 517 again! Here's the current text:
https://www.python.org/dev/peps/pep-0517/
We currently say:
All other hooks [except get_build_requires] are executed in an environment which contains both the bootstrap requirements specified in the pyproject.toml hook and those specified by the get_build_requires hook.
It's not clear to me whether this should be required for the build_sdist and prepare_build_files hooks, nor whether there are any adverse consequences of specifying it like this anyway. Thoughts?
I think we should rename get_build_requires to get_build_wheel_requires, and add a get_build_sdist_requires. And the rule would be: get_build_sdist_requires: can assume build-system.requires are available get_build_wheel_requires: can assume build-system.requires are available build_sdist: can assume build-system.requires and get_build_sdist_requires are available prepare_wheel_metadata, build_wheel: can assume build-system.requires and get_build_wheel_requires are available Rationale: (a) conceptually the sdist and wheel phases are totally separate, so we shouldn't couple them by requiring a single hook to provide the union of requirements for both. (b) there are known cases where building an sdist has different requirements than building a wheel. Examples: packages that run cython at sdist generation time. (This is not *as* necessary if we have robust build-time requirement support, but that's only one of the motivations for projects to do this now; others include avoiding a potentially expensive step for users -- installing cython in slow -- and avoiding the risk of later cython changes breaking an existing release.) In the broader world, it's very common to run automake/autotools etc. to generate ./configure scripts at sdist generation time. Maybe a python web app needs node installed to run its asset pipeline so they do that at sdist generation time rather than forcing end-users to install node. Etc. It's not immediately obvious to me how prepare_build_files would fit into this; if it's only supposed to be used for building from an sdist, then it's like an extra half-phase in between the sdist and wheel phases -- maybe it's more part of the wheel phase and should get the wheel requirements? Is that the only time it's used? I guess I'll wait to worry about it until after I see how people respond to my argument in the other thread that prepare_build_files shouldn't exist at all :-). -n -- Nathaniel J. Smith -- https://vorpus.org