On 30 July 2016 at 17:25, Stephen J. Turnbull
Xavier de Gaye writes: On the other hand, there doesn't seem to be demand for a "generic" sourceless distribution -- removing source is the *easy* part. In fact there are many use cases that *need* variants, so it seems to me that it would be likely to be a real hairball of optional features.
While you're not wrong about the complexity of the problem at hand, there are actually a few different problem domains pushing towards offering better mainline support for stripped down special purpose builds of the CPython runtime: - mobile devices - embedded devices - self-contained binaries - Linux container images (& even unikernels) These are all cases where "How do we make the core Python installation smaller?" is a reasonable question to ask (to either reduce storage requirements or to reduce network usage), and "use MicroPython instead of CPython" isn't always going to be the right answer (e.g. if you need CPython C API support). These are also all cases where the ability to automate builds and updates encourages pushing more complexity into the build process in pursuit of simplification and minimisation of the runtime components. If we say "pursue this problem outside the core", then odds are pretty good that those communities will all settle on different approaches, and we'll end up with four (or more) redundant sets of tooling and techniques for installation minimisation. By contrast, if we say "pursue improved solutions to this problem as part of CPython, but you'll need to keep these other potential use cases in mind", we increase the changes for "one obvious way" to be formulated, even if people have different motives for caring about the problem. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia