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

Alex Walters tritium-list at sdamon.com
Sun Oct 29 01:46:33 EDT 2017

At this point, I would punt to distutils-sig about curated packages, and pip tooling to support that, but they are bogged down as it stands with just getting warehouse up and running.  I don’t support putting specialized tooling in python itself to install curated packages, because that curation would be on the same release schedule as python itself.  Pip is an important special case, but it’s a special case to avoid further special cases.  If there was excess manpower on the packaging side, that’s where it should be developed.


From: Python-ideas [mailto:python-ideas-bounces+tritium-list=sdamon.com at python.org] On Behalf Of Guido van Rossum
Sent: Sunday, October 29, 2017 1:17 AM
To: Nick Coghlan <ncoghlan at gmail.com>
Cc: python-ideas at python.org
Subject: Re: [Python-ideas] Defining an easily installable "Recommended baseline package set"


Why? What's wrong with pip install? Why complicate things? Your motivation is really weak here. "beneficial"? "difficult cases"?


On Sat, Oct 28, 2017 at 8:57 PM, Nick Coghlan <ncoghlan at gmail.com <mailto:ncoghlan at gmail.com> > wrote:

Over on python-dev, the question of recommending MRAB's "regex" module over the standard library's "re" module for more advanced regular expressions recently came up again.

Because of various logistical issues and backwards compatibility risks, it's highly unlikely that we'll ever be able to swap out the current _sre based re module implementation in the standard library for an implementation based on the regex module.

At the same time, it would be beneficial to have a way to offer an even stronger recommendation to redistributors that we think full-featured general purpose Python scripting environments should offer the regex module as an opt-in alternative to the baseline re feature set, since that would also help with other currently difficult cases like the requests module.

What I'm thinking is that we could make some relatively simple additions to the `ensurepip` and `venv` modules to help with this:


1. Add a ensurepip.RECOMMENDED_PACKAGES mapping keyed by standard library module names containing dependency specifiers for recommended third party packages for particular tasks (e.g. "regex" as an enhanced alternative to "re", "requests" as an enhanced HTTPS-centric alternative to "urllib.request")

2. Add a new `install_recommended` boolean flag to ensurepip.bootstrap

3. Add a corresponding `--install-recommended flag to the `python -m ensurepip` CLI

4. Add a corresponding `--install-recommended flag to the `python -m venv` CLI (when combined with `--without-pip`, this would run pip directly from the bundled wheel file to do the installations)

We'd also need either a new informational PEP or else a section in the developer guide to say that the contents of `ensurepip.RECOMMENDED_PACKAGES` are up to the individual module maintainers (hence keying the mapping by standard library module name, rather than having a single flat list for the entire standard library).

For redistributors with weak dependency support, these reference interpreter level recommendations could become redistributor level recommendations. Redistributors without weak dependency support could still make a distinction between "default" installations (which would include them) and "minimal" installations (which would exclude them).

Folks writing scripts and example code for independent distribution (i.e. no explicitly declared dependencies) could then choose between relying on just the standard library (as now), or on the standard library plus independently versioned recommended packages.





Nick Coghlan   |   ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>    |   Brisbane, Australia

Python-ideas mailing list
Python-ideas at python.org <mailto:Python-ideas at python.org> 
Code of Conduct: http://python.org/psf/codeofconduct/


--Guido van Rossum (python.org/~guido <http://python.org/~guido> )

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171029/7d6fcd35/attachment-0001.html>

More information about the Python-ideas mailing list