[Python-Dev] Status of packaging in 3.3

[Nick Coghlan]

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.pypi_server — PyPI mock server
>>     packaging.fancy_getopt — 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:
- defining the command line interface and capabilities (pysetup)
- defining the programmatic API (packaging.pypi and the dependency
graph management)

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