On 22 May 2017 at 23:15, Paul Moore <p.f.mo...@gmail.com> wrote: > On 22 May 2017 at 12:28, Thomas Kluyver <tho...@kluyver.me.uk> wrote: >> What if it wants to send a character which can't be encoded in the >> locale encoding? It's quite easy on Windows to end up with a character >> that you can't encode as cp1252. If the build tool uses .encode(loc_enc, >> 'replace'), then you've lost information even before it gets to the >> install tool. >> >> It's 2017, I really don't want to go down the 'locale specified >> encoding' route again. UTF-8 everywhere! > > Hang on. Can we take a step back here? I just re-read the PEP and > remembered (!) that hooks are *in-process* Python entry points (I've > been working with pip's current backend-as-subprocess model, and mixed > up in my mind the original 2 proposals here). I think this encoding > debate may be a red herring.
No, that's discussed here: https://www.python.org/dev/peps/pep-0517/#comparison-to-competing-proposals Even though PEP 517 defines a Python API for build backends to implement, it still expects installation tools to wrap a subprocess call around the backend invocation. Frontends needs to do that in order to protect *their own* process state from bugs and design quirks in backend implementations: - no monkeypatching of parent process modules - no changes to the standard stream configuration - no persistent locale changes - no environment variable changes - no manipulation of any other process global state - calling sys.exit() won't cryptically crash the entire installation process - memory leaks won't cryptically crash the entire installation process - infinite loops won't *necessarily* crash the entire installation process (if the build has a timeout on it) - installation tools running with elevated privileges can readily run the build process with reduced privileges - installation tools can also readily run the build process in a chroot or containerised environment And in the context of this thread, it gives the frontend complete control over the stream output from not only the backend itself, but any child processes that it launches. That said, the whole "The build backend still runs in a subprocess" aspect should probably be separated out into its own section "Isolating build backends from frontend process state", rather than solely being covered in the "Comparison to PEP 516?" section, as it's a key aspect of the design - we expect each installation tool to provide its own CLI shim for calling build backends, rather than requiring all installation tools to use the same one. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
