[Python-Dev] Status of packaging in 3.3 (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Wed Jun 20 15:28:56 CEST 2012

On Wed, Jun 20, 2012 at 11:19 PM, Alexis Métaireau <alexis at notmyidea.org> wrote:

On 20/06/2012 14:53, Nick Coghlan wrote:

3.4 PEP: Standard library package downloader (pysetup) ---------------------------------- # Amongst other things, this needs to have a really good security story (refusing to install unsigned packages by default, etc) packaging.depgraph — Dependency graph builder packaging.pypi — Interface to projects indexes packaging.pypi.client — High-level query API packaging.pypi.base — Base class for index crawlers packaging.pypi.dist — Classes representing query results packaging.pypi.simple — Crawler using the PyPI “simple” interface packaging.pypi.xmlrpc — Crawler using the PyPI XML-RPC interface packaging.tests.pypiserver — PyPI mock server packaging.fancygetopt — Wrapper around the getopt module  # Why does this exist? I'm okay and willing to work on this part. I started a full review of the code I wrote years ago, and which clearly needs some cleaning. Alos, I'm not sure to understand what having a PEP to manage this means: should I describe all the API in a text document (with examples) so we can discuss this and validate before doing the changes/cleanings to the API?

There would be two main parts to such a PEP:

I would suggest looking at PEP 405 (venv) and PEP 397 (Windows launcher) to get an idea of the kind of content that might be appropriate. It's definitely not necessary to reproduce the full API details verbatim in the PEP text - it's OK to provide highlights and point to a reference implementation for the full details.

The PEP process can also be a good way to get feedback on an API design that otherwise may not be forthcoming (cf. the recent inspect.Signature discussions).

Cheers, Nick.

-- Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list