On 29 June 2017 at 11:42, Daniel Holth <dholth@gmail.com> wrote:
I was able to implement PEP 517 build_wheel and build_sdist for enscons (on bitbucket), and a click cli calling any backend mentioned in pyproject.toml. Pretty simple. Not sure what to do with the config dictionary.
That's designed to allow frontends to tunnel custom settings from the user through to the backend, so if you don't support any config settings yet, it probably makes sense to just error out with "Unknown config setting" if the dictionary is non-empty. Alternatively, you could silently ignore it.
SCons is not designed to be called twice in the same process with different arguments. It would be easier for me to know that pip would only invoke one PEP 517 function per subprocess, or to know all target directories in advance. Otherwise the enscons.api subprocess has to invoke SCons in another subprocess. SCons also builds all targets (wheel and sdist in same invocation) by default.
That's an interesting point of tension between supporting imperative frontends like pip (which have a strong opinion about the order in which steps should be executed) and declarative build systems like Scons (which are more "produce the defined artifact set"). However, I think the way to go for now would be to say: - each hook call should be made in a fresh subprocess (so backends don't need to use a second subprocess "just to be on the safe side") - in a *future* API extension, we may add an optional "build_all" hook (whereby the backend produced both an sdist and all wheels it knew how to create for the current platform), but anything like that will be out of scope for the initial PEP 517 API Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia