Re: [Python-Dev] Status of packaging in 3.3

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

> On Thu, Jun 21, 2012 at 7:28 PM, David Cournapeau <cour...@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