On Jun 3, 2017 4:47 AM, "Paul Moore" <p.f.mo...@gmail.com> wrote:
On 3 June 2017 at 04:53, C Anthony Risinger <c...@anthonyrisinger.com> wrote: > I want to make sure I understand what I'd need to do, as a user, in a post > PEP 517 world. Say I wanted to accomplish the following three things: > > * Generate version info from my VCS > * Generate .h and .c from .pyx or cffi's out-of-line API mode > * Use an alternative build process for a platform distutils isn't behaving > with (ignore this requirement if it leads to problems answering, we can just > as well assume distutils here) [...] So, basically the answer is that this is an open question for the new backend development ecosystem. But it's not something PEP 517 needs to take a view on. Fair enough. It seems like there will almost certainly emerge some way of chaining small "source tree mutators" (leading to an sdist) with truly custom build backends (that may ultimately terminate on either setuptools/distutils like you mention, or a completely separate toolchain [I want to say something like waf could be this alternate]). This wrapper/pipeline layer could be baked into pip/flit/whatever as a plugin system, but ideally it would just be a small and blessed pypa tool I'd think... then I suppose to make use of multiple transformations, a user would pass a list of actual build-system backends via tool.BLESSED-CHAINER-APP.build-backends in pyproject.toml or something. Is it unreasonable to request right now that build-system.build-backend be a repeatable key in pyproject.toml? Then I could just list them in order. Might be easy to add later without breakage though too. As long as all backends understand the hard separation between build_sdist "prepare the redistributable source tree" and build_wheel "construct an installable" they can be called in proper order and in phases. -- C Anthony
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
