> What happens when the new maintainer puts malware in the next release of > a package in sumo.txt? > Will core devs be blamed for listing it? > As a user, how do I determine if I can trust the packages there? (This > is easily the hardest part of finding and installing a package from > PyPI, though many people seem to skip it.)
I will point out that you quoted my entire post except for the most important line, the one which reads: > Just thinking out loud... I am still thinking out loud, so keep that in mind. (Perhaps this belongs on one of the two ideas groups, but this is where things started, so I will continue here for now.) Consider a hypothetical situation. - Suppose Python v. X is the last version delivered with batteries, so v. Y lacks a json module (assuming that's not determined to be so important that it must be delivered as part of the CPython installer proper) . - Downstream, some Linux distro realizes their users still want batteries (as do their Python admin tools), so recreates a Python package with them. Their package of v. Y *does* include (at least) the json battery. - One of the maintainers of the now externally maintained json battery takes it upon themselves to protest an incursion into East WhatsItStan by West WhatsItStan in the worst manner possible and inserts code to scrub disks of all West WhatsItStan-ian homed computers (as the primary maintainer of some widely installed (Node? JS?) package package did). - Some poor West WhatsItStan-ian upgrades their Linux distro, only to find when they next run their favorite Python application that their disk drive is wiped clean. Note that I haven't postulated the existence of a sumo.txt file. Whether the CPython distribution contains batteries or not, someone will recreate the batteries, if not in toto, at least piecemeal (some application or package depends on json and will blindly pull it in). Who gets the blame here? The core Python devs (because json "always came with Python")? The maintainers of the Linux distro for recreating the batteries but not having any West WhatsItStanian-based testers? The new maintainers of the now external (and corrupted) json package? Maybe the several levels of indirection would serve to insulate the Python devs, but maybe not. > If they do exert control, why not keep it in stdlib? Perhaps that is the best route. Someone here (Stéfane Fermigier, it seems) questioned whether batteries included are such a good idea. It's quite possible that enough core devs disagree with that sentiment that the batteries will stay (and perhaps grow in number, though more slowly than in the past). That said, if enough devs agree with Stéfane, then what's the best route forward? Discard all batteries and let the chips fall where they may? Extract the dead batteries (and presumably their docs and test bits) into separate github.com/python repositories? Ask others to extract them into their own non-github.com/python repositories? One of the common reasons old platform support is dropped from CPython (OS/2 or AmigaOS anyone?) is that the maintenance load for the core devs is too high relative to the community benefit derived from supporting small minority platforms. The unlucky modules named by PEP 594 are about to suffer the same fate. (I'm not arguing that they shouldn't be deleted.) Once PEP 594 has been implemented, all the low-hanging fruit will have been picked. At that point, it's keep everything or keep (almost) nothing. I think that will largely depend on the willingness of the core devs to keep maintaining modules they may well never use in their own work (like getopt and wave). One thing I think is obvious. If you remove all the batteries not deemed absolutely essential to build and test CPython, I think you have to somehow symbolically say, "these correspond to the various batteries which used to be in the CPython distribution." Maybe it's text in a README file, a new PEP, a sumo.txt file, or a Linux distro's packaging. Skip P.S. Personally, I was never fond of shutil or the logging package (as two examples — though for different reasons). We might have something better in both realms by now if they hadn't been added to the stdlib long ago. This ability of presence in the stdlib to forestall further development might well be the strongest argument to remove most batteries. On the other hand, we seem to have had little trouble cycling through several completely different regular expression modules. Maybe I'm just imagining a barrier where none exists.
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PPGY7Q2OWFJ6JYUDAXWVW2HDGEK47C2I/ Code of Conduct: http://python.org/psf/codeofconduct/
