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

David Cournapeau cournape at gmail.com
Thu Jun 21 14:19:53 CEST 2012

On Thu, Jun 21, 2012 at 12:58 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

On Thu, Jun 21, 2012 at 7:28 PM, David Cournapeau <cournape at gmail.com> wrote: > If specifying install dependencies is the killer feature of setuptools, why > can't we have a very simple module that adds the necessary 3 keywords to > record it, and let 3rd party tools deal with it as they wish ? That would > not even require speciying the format, and would let us more time to deal > with the other, more difficult questions.

That low level role is filled by PEP 345 (the latest PyPI metadata format, which adds the new fields), PEP 376 (local installation database) and PEP 386 (version numbering schema). The corresponding packaging submodules are the ones that were being considered for retention as a reference implementation in 3.3, but are still slated for removal along with the rest of the package (the reference implementations will remain available as part of distutils2 on PyPI).

I understand the code is already implemented, but I meant that it may be a good idea to have a simple, self-contained module that does just provide the necessary bits for the "setuptools killer feature", and let competing tools deal with it as they please.

Whatever UI a Python packaging solution presents to a user, it needs to support those 3 PEPs on the back end for interoperability with other tools (including, eventually, the packaging module in the standard library).

Your feedback on the commands/compilers design sounds valuable, and I would be very interested in seeing a PEP targeting that aspect of the new packaging module (if you look at the start of this thread, the failure to improve the compiler API is one of the reasons for pulling the code from 3.3).

The problem with compilation is not just the way the compiler classes work. It it how they interact with commands and the likes, which ends up being most of the original distutils code. What's wrong with distutils is the whole underlying model, if one can call that. No PEP will fix the issue if the premise is to work within that model.

There are similar kind of arguments around the extensibility of distutils: it is not just about monkey-patching, but what kind of API you offer to allow for extensibility, and I think the only way to design this sensibly is to work on real packages and iterate, not writing a PEP as a first step.

David -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20120621/1bb94263/attachment.html>

More information about the Python-Dev mailing list