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