[Python-ideas] Defining an easily installable "Recommended baseline package set"

[Nick Coghlan]

On 29 October 2017 at 19:51, Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Sun, 29 Oct 2017 17:54:22 +1000
> Nick Coghlan <ncoghlan at gmail.com> wrote:
> >
> > The underlying problem is that our reasons for omitting these particular
> > libraries from the standard library relate mainly to publisher side
> > concerns like the logistics of ongoing bug fixing and support, *not* end
> > user concerns like software reliability or API usability.
>
> They're both really.  One important consequence of a library being in
> the stdlib is to tie it to the stdlib's release cycle, QA
> infrastructure and compatibility requirements -- which more or less
> solves many dependency and/or version pinning headaches.
>

For the QA & platform compatibility aspects, one of the things actually
defining a specific extended package set would let us do is to amend the
test suite with a new "third-party" resource, whereby we:

1. Named specific known-working versions in the recommended-packages.txt
file (updating them for each maintenance release)
2. Added a new test case that installed and ran the test suites for these
projects in a venv (guarded by "-uthird-party")


> > This means that
> > if educators aren't teaching them, or redistributors aren't providing
> them,
> > then they're actively doing their users a disservice
>
> Which redistributors do not provide the requests library, for example?
> regex is probably not as popular (mostly because re is good enough for
> most purposes), but it still appears to be available from Ubuntu and
> Anaconda.
>

The existing commercial redistributors have been doing this long enough now
that they offer the most popular third party packages.

Where folks can get into trouble is when they're putting their own bespoke
environments together based directly on the python.org installers, and that
quite often includes folks teaching themselves from a book or online
tutorial (since book and tutorial authors are frequently reluctant to
favour particular commercial vendors, and will hence direct readers to the
python.org downloads instead).


> > All the proposal does is to suggest taking those existing recommendations
> > from the documentation and converting them into a more readibly
> executable
> > form.
>
> I'm curious what such a list looks like :-)
>

regex and requests are the two cases I'm personally aware of that already
have "You'll probably want to look at this 3rd party option instead" links
at the beginning of the related standard library module documentation.

ctypes should probably have a similar "Consider this alternative instead"
pointer to cffi, but doesn't currently have one.

All three of those (regex, requests, cffi) have received "in principle"
approval for standard library inclusion at one point or another, but we
haven't been able to devise a way to make the resulting maintenance
logistics work (e.g. bringing in cffi would mean bringing in pycparser,
which would mean bringing in PLY...)

six should be on the recommended packages list for as long as 2.7 is still
supported (and potentially for a while after)

setuptools is currently brought in implicitly as a dependency of pip, but
would also belong on a recommended packages list in its own right as an
enhanced alternative to distutils (https://docs.python.org/3/distutils/
indirectly recommends that by pointing to the
https://packaging.python.org/guides/tool-recommendations/ page)

Beyond those, I think things get significantly more debatable (for example,
while datetime doesn't currently reference pytz as a regularly updated
timezone database, most ad hoc scripts can also get away with working in
either UTC or local time without worrying about arbitrary timezones, which
means that use case is at least arguably already adequately covered by
explicit dependency management).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171030/13d693f6/attachment-0001.html>