On 2019-05-21, Brett Cannon wrote:
> On Tue., May 21, 2019, 13:07 Neil Schemenauer, <nas-pyt...@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
provide.

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:

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

    python3-stdlib-deprecated
        packages suggested for removal by PEP 594

    python3-stdlib-broken
        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.

    python3-stdlib-all
        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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to