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

[Steven D'Aprano]

Thanks Steve for your comments, I appreciate them. As I said I don't 
know if this is a good idea or not so please read my responses below as 
part of a friendly debate aimed at reaching consensus, not an argument.

(The argument is in Room 12 with Mr. Barnard.)


On Fri, May 24, 2019 at 09:54:05AM -0700, Steve Dower wrote:
> 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.

If nobody reads warnings, we should just remove the warnings module and 
be done with it. That should probably be a PEP.


> >- 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.

Can somebody quantify how much time will be saved?

Will we be saving 5 seconds in a 20 minute test suite, or 1 minute in a 
2 minute test suite?


 
> >- 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.

No, that won't be the same.

Keeping the import name the same is only valuable if we're not breaking 
backwards compatibility. If we remove the module from the std lib, we've 
broken backwards compatibility and people's code will still be broken, 
same name or not.


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

By anyone with the ability to close bug reports. On bugs.python.org 
that's anyone with an account, you don't need to be a core developer, 
and some volunteers help out by triaging or closing poor-quality bug 
reports long before the core developers get involved.

I assume the same applies on github -- if it doesn't, that's a huge 
usability regression.


> >- 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.

Is that true? That's certainly the *impression* people are giving, but 
the PEP is light on examples or details. The one example I looked into, 
binhex, didn't seem particularly troublesome.

https://mail.python.org/pipermail/python-dev/2019-May/157673.html

Although I may have missed some examples.



> How long do we have to wait?

How long do we wait before closing any other ticket? Less than that, 
because these would be unmaintained.


> >- 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.

Indeed we could. The question is whether we should.


> >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.

They're unmaintained. Nobody is promising to read or review bug 
reports. Volunteers will surely do the bulk of triaging (as I think they 
already do now). And besides, if it is correct that nobody is using 
these modules, who will be making the bug reports?


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

No, nothing like PyPI, for reasons discussed many times before including 
some of my earlier posts.

Every Python user has access to whatever is in the std lib (exception: 
some Linux distros split out parts of the std lib into packages that 
need to be apt-installed or equivalent). Not all Python users can use 
third-party libraries on PyPI.

Moving things to PyPI is an implicit decision to cut some users out.


> >- other implementations are under no obligation to distribute
> >   unmaintained modules.
> 
> a.k.a. PyPI?

No, nothing like 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.

That's not a "maintenance burden" since there's no maintenance involved. 
At worst its a small annoyance to the volunteers who close invalid bug 
reports on the tracker.

If there is a flood of bug reports for unmaintained modules, that will 
be objective evidence that the module is broken and we can remove it for 
real.


[...]
> 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).

That's a very privileged point of view. People contribute to Open Source 
software for many reasons -- the fame, the money, the power *wink* -- 
but surely its not *mandatory* that Python is only for those with the 
skills, time or money to contribute back.

We might not have an obligation to maintain software forever, but to the 
degree that we do have an obligation to our users, we should consider 
those who cannot contribute.

I'm suggesting that there's a middle step for modules, between 
being fully maintained and distributed, and being fully abandoned and 
removed, its users left to fend for themselves.

And that is to formally say we aren't maintaining this any more, but 
we'll still distribute it until even that becomes a burden. If it helps, 
the path becomes:

- fully maintained and distributed

- deprecation warnings in docs and software

- move to "unmaintained" status (distributed but not maintained)

- cease distributing.

With the last step only happening if and when there's objective evidence 
that the code is dead, or if closing bug reports becomes a burden, and 
nobody has stepped up in the intervening years with either money or time 
to fix the module.


-- 
Steven