git.net

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

[Python-Dev] PEP 594 - a proposal for unmaintained modules


On 23May2019 2355, Steven D'Aprano wrote:
> I don't know if this is a good idea or a terrible idea or somewhere in
> between, so I'm throwing it out to see if anyone likes it.
> 
> Let's add a third option to PEP 594 between "keep" and "remove":
> explicitly flagging a module as unmaintained. Unmaintained modules:
> 
> - will raise a warning when imported that they are unmaintained;

Nobody reads warnings.

> - will have their tests disabled;

I'm fine with this. Reducing time to run the test suite is the biggest 
immediate win from removing unmaintained modules.

> - possibly we move them into a seperate namespace:
>    ``from unmaintained import aardvark``

May as well move them all the way to PyPI and leave the import name the 
same.

> - bug reports without patches will be closed Will Not Fix;

By whom?

> - bug reports with patches *may* be accepted if some core dev is
>    willing to review and check it in, but there is no obligation
>    to do so;

Historically, nobody has been willing to review and merge these modules 
for years. How long do we have to wait?

> - should it turn out that someone is willing to maintain the module,
>    it can be returned to regular status.

Or we can give them the keys to the PyPI package. Or help pip implement 
the "Obsoleted By" header and redirect to a fork.

> Plus side:
> 
> - reduce the maintenance burden (if any) from the module;

Apart from having to read, review, and decide on bug reports, CVEs, and 
documentation.

> - while still distributing the module and allowing users to use
>    it: "no promises, but here you go";

a.k.a. PyPI?

> - other implementations are under no obligation to distribute
>    unmaintained modules.

a.k.a. PyPI?

> Minus side:
> 
> - this becomes a self-fulfilling prophesy: with tests turned off,
>    bit-rot will eventually set in and break modules that currently
>    aren't broken.

True. And then we have the added maintenance burden of explaining 
repeatedly that we don't care that it's broken, but we want to put it on 
your machine anyway.

All in all, this is basically where we are today, with the exception 
that we haven't officially said that we no longer support these modules. 
PEP 594 is this official statement, and our usual process for things we 
don't support is to remove them in two versions time. It doesn't have to 
be so controversial - either the people who are saying "we rely on this" 
are also willing to help us maintain them, or they're not. And if 
they're not, they clearly don't rely on it (or realize the cost of 
relying on volunteer-maintained software).

Cheers,
Steve