<div dir="ltr">There are already curated lists of Python packages, such as:<br><div><br><a href="https://github.com/vinta/awesome-python">https://github.com/vinta/awesome-python</a><br><br></div><div>Even better, if you don't agree, you can just clone it and create your own ;-)<br><br></div><div>Stephan<br></div><div><div class="gmail_extra"><br><div class="gmail_quote">2017-10-29 6:46 GMT+01:00 Alex Walters <span dir="ltr"><<a href="mailto:tritium-list@sdamon.com" target="_blank">tritium-list@sdamon.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_7460517802805948637WordSection1"><p class="MsoNormal">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.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><div style="border-width:medium medium medium 1.5pt;border-style:none none none solid;border-color:currentcolor currentcolor currentcolor blue;padding:0in 0in 0in 4pt"><div><div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(225,225,225) currentcolor currentcolor;padding:3pt 0in 0in"><p class="MsoNormal"><b>From:</b> Python-ideas [mailto:<a href="mailto:python-ideas-bounces%2Btritium-list" target="_blank">python-ideas-bounces+<wbr>tritium-list</a>=<a href="mailto:sdamon.com@python.org" target="_blank">sdamon.com@<wbr>python.org</a>] <b>On Behalf Of </b>Guido van Rossum<br><b>Sent:</b> Sunday, October 29, 2017 1:17 AM<br><b>To:</b> Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>><br><b>Cc:</b> <a href="mailto:python-ideas@python.org" target="_blank">python-ideas@python.org</a><br><b>Subject:</b> Re: [Python-ideas] Defining an easily installable "Recommended baseline package set"<u></u><u></u></p></div></div><div><div class="gmail-h5"><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">Why? What's wrong with pip install? Why complicate things? Your motivation is really weak here. "beneficial"? "difficult cases"?<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Sat, Oct 28, 2017 at 8:57 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<u></u><u></u></p><blockquote style="border-width:medium medium medium 1pt;border-style:none none none solid;border-color:currentcolor currentcolor currentcolor rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in"><div><div><div><div><div><div><div><div><div><div><p class="MsoNormal" style="margin-bottom:12pt">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.<u></u><u></u></p></div><p class="MsoNormal" style="margin-bottom:12pt">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.<u></u><u></u></p></div><p class="MsoNormal" style="margin-bottom:12pt">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.<u></u><u></u></p></div><p class="MsoNormal">What I'm thinking is that we could make some relatively simple additions to the `ensurepip` and `venv` modules to help with this:<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><p class="MsoNormal" style="margin-bottom:12pt">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")<u></u><u></u></p></div><p class="MsoNormal" style="margin-bottom:12pt">2. Add a new `install_recommended` boolean flag to ensurepip.bootstrap<u></u><u></u></p></div><p class="MsoNormal" style="margin-bottom:12pt">3. Add a corresponding `--install-recommended flag to the `python -m ensurepip` CLI<br><br>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)<u></u><u></u></p></div><p class="MsoNormal" style="margin-bottom:12pt">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_<wbr>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).<u></u><u></u></p></div><p class="MsoNormal" style="margin-bottom:12pt">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).<u></u><u></u></p></div><p class="MsoNormal">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.<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p><div><div><div><div><div><div><p class="MsoNormal">Cheers,<u></u><u></u></p></div><div><p class="MsoNormal">Nick.<span style="color:rgb(136,136,136)"><br clear="all"></span><u></u><u></u></p></div><div><div><div><div><p class="MsoNormal"><span style="color:rgb(136,136,136)"><br>-- <u></u><u></u></span></p><div><p class="MsoNormal"><span style="color:rgb(136,136,136)">Nick Coghlan | <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a> | Brisbane, Australia<u></u><u></u></span></p></div></div></div></div></div></div></div></div></div></div></div></div><p class="MsoNormal" style="margin-bottom:12pt"><br>______________________________<wbr>_________________<br>Python-ideas mailing list<br><a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br><a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>Code of Conduct: <a href="http://python.org/psf/codeofconduct/" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><u></u><u></u></p></blockquote></div><p class="MsoNormal"><br><br clear="all"><br>-- <u></u><u></u></p><div><p class="MsoNormal">--Guido van Rossum (<a href="http://python.org/%7Eguido" target="_blank">python.org/~guido</a>)<u></u><u></u></p></div></div></div></div></div></div></div><br>______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
<br></blockquote></div><br></div></div></div>