[Python-Dev] Breaking up the stdlib (Was: release cadence)

[Brett Cannon]

On Tue, 5 Jul 2016 at 13:02 Paul Moore <p.f.moore at gmail.com> wrote:

> On 5 July 2016 at 19:01, Petr Viktorin <encukou at gmail.com> wrote:
> > There are people who want to cut out what they don't need – to build
> > self-contained applications (pyinstaller, Python for Android), or to
> > eliminate unnecessary dependencies (python3-tkinter). And they will do
> > it with CPython's blessing or without.
> [...]
> > It would be much better for the ecosystem if CPython acknowledges this
> > and sets some rules (like "here's how you can do it, but don't call the
> > result an unqualified Python").
>
> That doesn't sound unreasonable in principle. As a baseline, I guess
> the current policy is essentially:
>
> """
> You can build your own Python installation with whatever parts of the
> stdlib omitted that you please. However, if you do this, you accept
> responsibility for any consequences, in terms of 3rd-party modules not
> working, or even stdlib breakage (for example, we don't guarantee that
> parts of the stdlib may not rely on other parts).
> """
>
> That's pretty simple, both to state and to adhere to. And it's
> basically the current reality. What I'm not clear about is what
> *additional* guarantees people want to make, and how we'd make them.
> First of all, Python's packaging ecosystem has no way to express "this
> package won't work if pathlib isn't present in your stdlib". It seems
> to me that without something like that, it's pretty hard to support
> anything better than the current position with regard to 3rd party
> modules. Documenting stdlib inter-dependencies may be possible, but I
> wouldn't like to make "X doesn't depend on Y" a guarantee that's
> subject to backward compatibility rules.
>
> Maybe the suggestion is to provide better tools for people wanting to
> *build* such stripped down versions? That might be a possibility, I
> guess. I don't know much about how people build their own copies of
> Python to be able to comment.
>
> So I guess my question is, what is the actual proposal here? People
> seem to have concerns over things that aren't actually being proposed
> - but without knowing what *is* being proposed, it's hard to avoid
> that.
>

Realizing that all of these are just proposals with no solid plan behind
them, they are all predicated on moving to GitHub, and none of these are
directly promoting releasing every module in the stdlib on PyPI as a
stand-alone package with its own versioning, they are:

   1.  Break the stdlib out from CPython and have it be a stand-alone repo
   2. Break the stdlib up into a bunch of independent repos that when
   viewed together make up the stdlib (Steve Dower did some back-of-envelope
   grouping and pegged the # of repos at ~50)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20160705/7ff30aca/attachment.html>