[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] PEP 594: Removing dead batteries from the standard library

On 2019-05-21, Brett Cannon wrote:
> On Tue., May 21, 2019, 13:07 Neil Schemenauer, <nas-python at arctrix.com>
> wrote:

> > Here is an alternative, straw man, proposal.  Split the CPython repo
> > into two parts:
> >
> >     - core Python: minimal possible stdlib
> >     - everything else
> How to this lighten the burden of maintaining those modules which aren't in
> the core install? Are you suggesting modules in the core install get
> serious focus and the rest is more of a legacy, unsupported release for
> some time to give people an extended period to shift to the core install?
> Or do you have something else in mind?

It would give us the freedom to choose how we want to do it.  It
would give a lightweight Python install for the people who don't need
all the batteries, much lighter than what the PEP 594 strategy could

For CI, we can decide what should be tested.  Obviously the core
part is always tested.  Initially, we could continue testing all
parts of non-core.  Later, we could decide that certain parts of
non-core get tested less often (e.g. full nntplib tests only
nightly).  BTW, I think it would be great if automated nightly jobs
could also also run tests for PyPI modules like NumPy, requests,
Pandas, etc.

The installers could offer options as to which parts of the non-core
library to install.  Modules that no longer receive the same quality
of development and testing could get moved to a "deprecated"
section.  Users who want the best backwards compatibility would
install everything.  If we want to remove something from the
"deprecated" section, I think we should give a lot of notice.  A
couple of years is not enough.

Here is a sketch for a Linux-like package system:

        all recommended stdlib packages (e.g. same as stdlib after
        PEP 594 removals)

        packages suggested for removal by PEP 594

        packages that have bugs or are really not recommended to
        be used.  I'm not sure if we need this but stuff like crypt
        could go here.

        depends on the above three packages

Ideally these packages don't contain the module files themselves.
Instead, they depend on individual packages for each module.  E.g.
python3-stdlib-deprecated would depend on python3-nntplib.  So,
someone could install python3-stdlib-base and python3-nntplib if
that's all they need.

I'm not familiar with the internals of 'pip' but I would guess we
could do a similar thing by creating meta PyPI packages that
correspond to these sets of packages.  So, someone could download
the small "core" Python installer and then run:

    pip install stdlib-base

or something like that.