On Mon, 28 Mar 2022 at 17:45, Steve Dower <steve.do...@python.org> wrote:
>
> I think to most people "batteries included" doesn't necessarily mean
> "standard library," with all that implies. It just means "it came with
> the first thing that I installed" (or alternatively, "at no additional
> charge").
I think that for users it means "came as part of the official
installer" where "official" means "whoever I chose to trust" - which
in turn often means "python.org".
For package maintainers it means "the bunch of stuff I can assume
exists when someone says they have python" - which is why distros that
debundle parts of the stdlib get so much grief. Also note that "just
add a dependency" is not a simple request for a library maintainer -
if I depend on requests, and someone using my library uses httpx, then
I'm imposing a potential transitive dependency conflict on them. So
using stdlib functionality is a non-trivial advantage for library
maintainers (of course, sometimes the benefits of using a 3rd party
library outweigh this, but not always).
> Given there are *plenty* of existing distros out there that install more
> than just the standard library for the benefit of their users, and yet
> the people asking for a fatter stdlib don't seem to want them, perhaps
> we just need to officially endorse one?
But people don't use those existing options presumably for a reason.
Having the core devs say "distro X is approved" won't remove those
reasons. And removing the python.org distro because X is now approved
will create a problem for those users.
And none of this alters the fact that "stdlib" means "can be assumed
to be present in all Python installations" for some use cases.
> I've got no issue preinstalling a curated sumo.txt into the Windows
> installers, provided we're clear about support (i.e. none from us) and
> someone besides me is tracking everything in that curated list. That
> probably requires new volunteers who are somehow already trustworthy,
> but that should be easier than people to actually write and maintain new
> functionality on stdlib timelines.
"Support" is a somewhat ambiguous matter in the context of
volunteer-supported software. The point of having a stdlib is that
people know where to report issues, not that we're necessarily any
more responsive than a 3rd party maintainer. There's a value in
knowing that if you find an issue with "anything you installed as part
of the basic Python install", you report it in the same place. And
having the documentation all in one place. Etc.
Yes, people come along and make a big fuss about how they expect more
in the way of support ("this bug is urgent, my production system is
failing because of it") and yes, people with that attitude have a
negative effect on core developer morale. But we don't promise fixes,
or solutions. At best there's an implication that the core devs care
about the stdlib in some sort of vague, generalised sense. (I care
about the health of the stdlib, but I'm not likely to try to fix a bug
in ossaudiodev, for example).
If we did try to mandate something more concrete, then maybe the
conversation would be different. But I'm not aware of anyone proposing
anything like that.
> We would still have to have the "light" distribution, as many of our
> users wouldn't be able to use a "this is full of unsupported stuff"
> package, but at least most users could be pointed to the bigger install
> by default and not even care that the batteries just came in the same
> package and aren't actually an integral part of the core product.
To be honest, I feel like I'm just reiterating stuff I've said before
here, and I think the same is true of the points I'm responding to. Is
there actually any new development here, or is it just a repeat of the
same positions people have expressed in the past, based on the same
underlying realities? (I'm not *against* going over the debate again,
it helps make sure people haven't changed their minds, but it's
important to be clear that none of the practical facts have changed,
if that is the case).
I should also point out (as someone heavily involved in Python's
packaging ecosystem) that I don't believe that the existing packaging
infrastructure is sufficiently robust to support a world where the
Python stdlib was all delivered as external packages. And even if it
were, bootstrapping something like pip would be a nightmare - for a
start, we don't vendor libraries that include C extensions, so we
could only handle pure Python stdlib modules - and even vendoring all
of them (and all of our vendored tools' stdlib dependencies) would be
a nightmare.
Paul
_______________________________________________
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/SKIKUC4U3L74G43BNC5SDCXFYUY3G447/
Code of Conduct: http://python.org/psf/codeofconduct/
