<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#330033" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Between this discussion and Steve
Dower's recently referenced blog post at
<a class="moz-txt-link-freetext" href="https://devblogs.microsoft.com/python/python-in-the-windows-10-may-2019-update/from">https://devblogs.microsoft.com/python/python-in-the-windows-10-may-2019-update/from</a>
which I quote below:<br>
<br>
<blockquote type="cite">It’s been widely known for many years that
Windows is the only mainstream operating system that does not
include a Python interpreter out of the box.</blockquote>
<br>
and Victor's and Eric's work to make embedding Python easier, it
makes me wonder when emacs will include a Python interpreter as an
extension language.<br>
<br>
<br>
On 5/22/2019 2:26 AM, Stephen J. Turnbull wrote:<br>
</div>
<blockquote type="cite"
cite="mid:23781.5568.183871.73668@turnbull.sk.tsukuba.ac.jp">
<pre class="moz-quote-pre" wrap="">Neil Schemenauer writes:
> Here is an alternative, straw man, proposal. Split the CPython repo
> into two parts:
>
> - core Python: minimal possible stdlib
> - everything else
I take issue with the characterization of "straw man," it's a
practical idea that turns out to be not so easy to implement.
We tried to do this with XEmacs, and found it just didn't work for us.
It requires a lot of effort to pare a distribution down to a minimal
core. (In fact, we never got close.) We gave up on that idea after
only a year, and this was an age and an environment that did not have
pip-like support for installation of 3rd-party packages (which you
deprecate as "not really a great solution"), and a lot of people were
still downloading at ISDN speeds or worse. The demand for a minimal
core was correspondingly greater than today, I think.
We did bundle most applications such as MUAs and even C/C++
development support into sumo packages (one for general use, one for
packages that didn't function at all without the "MULE" multilingual
environment which was optional in XEmacs). But we still ended up with
many packages staying in the core distribution, because other parts of
the core or the installation process used them, and as you say "If I
have a script that uses one of these modules and it gets removed, my
script breaks." That annoyed core developers as much as anyone, and
they generally had priorities that did not emphasize minimalism (to
say the least).
> When Python is released, provide installers for a Python that only
> includes the "core" part and a second installer that includes
> everything else. I realize this is more work for the release team.
> Hopefully with some scripting, it will not be too labour intensive.
Creating the distributions (core and sumo) was not particularly
labor-intensive for us because we mostly didn't distribute binaries.
A few moderately baroque scripts did the trick. Automation has
advanced, but due to the amount of it it's still fragile, especially
when you're producing turn-key binary installers.
As I mentioned above, it wasn't the release process that was the
bottleneck, it was other factors that made it hard to reduce the
core. We had an "xemacs-base" package that provided a set of "extra
tools" that some packages required, and libraries moved in and out of
it pretty much every release as some developer got tired of telling
people to install xemacs-base (back to core) or working around missing
features (move it to xemacs-base where it could be updated easily).
These are the same things that Python maintainers mention as pros and
cons of having things in stdlib or out on PyPI. We learned there is a
sweet spot. I know we didn't hit it most of the time, but it's very
clear that both extremes are hard, if not infeasible, to maintain.
(At the maximalist extreme, even GNU Emacs doesn't really try to
include everything written in Emacs Lisp any more.)
> To help the people who need 100s or 1000s of extra PyPI packages,
> we could develop a tool that creates a "sumo" Python installer,
> grabbing packages from PyPI and building a installer package.
This could be done by any third party (it wouldn't even need to be a
public distribution, it could easily be an enterprise that open
sources an internal tool or a GSoC project). And it could be hosted
on PyPI itself, since it's not the kind of thing that enterprises need
to install on 100,000 workstations.
> To install that package, you would not need network access.
AIUI, it's not the network access that is usually the problem these
days, although it can be annoying if net access is flaky or if you
have to sneakernet USBs around. Still, "sneakernet" is basically a
one-off cost. The problem is that collections of random software from
untrusted sources are verboten in the enterprise. (Ah, those Walnut
Creek CDs were wonderful! I wonder what a modern AV tool would find
in them?!) I suppose that in those situations people already have the
necessary tooling to roll the sumo or provide an intranet repository;
the problem is navigating the red tape.
> That doesn't need to happen right away. Also, maybe other Python
> distributions can fill that need if core Python devs don't want to
> build it.
I don't think this is about what core devs do or don't want to build.
I also don't feel a strong sense among the core developers that they
don't want to maintain a "batteries included" standard library. Sure,
there's Christian's PEP, but there's also deliberate activity to
promote more participation at the core (ie, committer) level. AIUI,
Christian's PEP is about transparency of what is already happening
(WONTFIX-ing or long periods of inactivity on issues with modules of
"low importance" to the active core developers), and a first step
toward making a managed process for the deprecation of modules we
can't afford to maintain given others we have committed to maintain.
Steve
</pre>
</blockquote>
<br>
</body>
</html>