[Python-ideas] size of the installation of Python on mobile devices

[Stephen J. Turnbull]

Nick Coghlan writes:
 > On 1 August 2016 at 15:46, Stephen J. Turnbull
 > <turnbull.stephen.fw at u.tsukuba.ac.jp> wrote:
 > > Victor Stinner writes:
 > >
 > >  > Xavier is a core developer.  He is free to dedicate his time to
 > >  > supporting sourceless distribution :-)
 > >
 > > So are we all, core or not.  But on Nick's terms (he even envisions
 > > releases with the "sourceless" build broken), I don't think adding to
 > > core is fair to Xavier's (and others') efforts in this direction.
 > 
 > How would it be any different from our efforts to support other
 > platforms outside the primary set of Windows, Mac OS X, Linux, and
 > *BSD?

This isn't platform support in the same sense, for one.  This is a
variant distribution mode.  A better analogy would be the common
packaging support we provide for RPMs, debs, and all the whatnots
associated with different Linux and *BSD distros.  AFAIK there is no
such support, rather we leave it up to the individual distros, which
mostly ignore our own packaging technologies (except where implied by
directory structure).  (OK, there's probably stuff in Tools that can
be applied to that, but all I see that's obvious is a *distribution-
specific* facility, Misc/RPM, which is regularly used.)

Second, such platforms typical provide or lack features that *require*
changes to the compilation of the interpreter or stdlib modules.  By
contrast, Xavier's core list can be provided by script AFAICS.

 > Things *definitely* break from time-to-time on those other less common
 > setups, and when they do, folks submit patches to fix them after they
 > notice (usually because they went to rebase their own work on a newer
 > version and discovered things didn't work as expected). I'd see this
 > working the same way - we wouldn't go out of our way to break
 > sourceless builds, but if they did break, it would be on the folks
 > that care about them to submit patches to resolve the problem.

I understand the functional similarity.  I don't think the incentives
are the same.  If Python crashes on your platform, you *must* fix
Python, and you've fixed it for everybody using the same platform.  In
sourceless, if the build process leaves pyc turds or lacks something
you actually need, you may change your specialized build scripts that
do all the other stuff you need, and maybe even stop using Python's
sourceless support (eg, in the missing requirements case).  It's not
yet clear that the same fixes will be appropriate for all sourceless
distros.

 > The gain for folks that care would be getting a green light to pursue
 > more robust support for that model in the standard library itself,
 > such as clearly marking test cases that require linecache to be
 > working

How does that green light depends on patches to the Makefile?

 > and perhaps even eventually developing a mechanism along the lines
 > of JavaScript sourcemaps that would allow linecache to keep
 > working, even when running on a sourceless build of the standard
 > library.

Why not wait until such features are in development, and at the same
time declare sourceless a supported distribution mode?

 > > It would also set an unfortunate precedent.
 > 
 > What precedent do you mean? That ./configure may contain options that
 > aren't 100% reliable? That's already the case - I can assure you that
 > we *do not* consistently test all of the options reported by
 > "./configure --help", since what matters is that the options people
 > are *actually using* keep working

It appears that you're arguing that this feature won't be used so it
doesn't matter if it works.<wink multiplier=1.0 />

Nothing is 100% reliable, that's a red herring.  The precedent I refer
to is adding code of uncertain value and completeness, that will
require maintenance by somebody, on speculation that it will be used.

I suggest that this patch is premature optimization.  It's more
efficient to not add __pycache__ directories in the first place, but
it's not necessary to do it that way, it can be done by a separate
script.  I believe that is true of all of the three options Xavier
proposed -- a bash script would probably be fewer than 10 pipelines.
If these were done by a script that could be jointly designed and
maintained in a separate project by the sourceless distributors, it
would be a lot more effective in discovering the common features that
all of them use in the same way, and even more so for important
features that only a subset use.

Once there are features that *must* be done in the core build process
(eg, linecache sourcemap), then it would be timely to move the common
features there.

IOW, I don't see why the usual arguments for "put it on PyPI first"
don't apply here, with the usual strength.

 > Or do you mean the precedent that we're OK with folks shipping the
 > standard library sans source code?

Of course *I* don't mean that.  If an economist fails to understand
the implications of licensing, he should change careers.