There are already curated lists of Python packages, such as: https://github.com/vinta/awesome-python
Even better, if you don't agree, you can just clone it and create your own ;-) Stephan 2017-10-29 6:46 GMT+01:00 Alex Walters <tritium-l...@sdamon.com>: > 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@ > python.org] *On Behalf Of *Guido van Rossum > *Sent:* Sunday, October 29, 2017 1:17 AM > *To:* Nick Coghlan <ncogh...@gmail.com> > *Cc:* python-ideas@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 <ncogh...@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. > > > > Cheers, > > Nick. > > > -- > > Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia > > > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > > > > -- > > --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>) > > _______________________________________________ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
