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

On Thu, Jun 21, 2012 at 10:19 PM, David Cournapeau <cour...@gmail.com> wrote:
>>> 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.

If you're genuinely interested in that prospect, I suggest
collaborating with the distutils2 team to extract the four identified
modules (and any necessary support code) as a "distmeta" project on
PyPI:

        distmeta.version — Version number classes
        distmeta.metadata — Metadata handling
        distmeta.markers — Environment markers
        distmeta.database — Database of installed distributions

That will allow faster iteration on the core interoperability
standards prior to reincorporation in 3.4, and explicitly decouple
them from the higher level (more contentious) features.

>> 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.

I don't accept the premise that the 3.4 packaging solution must be
restricted to the distutils semantic model. However, no alternative
strategy has been formally presented to python-dev.

Regards,
Nick.

-- 
Nick Coghlan   |   ncog...@gmail.com   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Pyth...@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-dev-ml%40activestate.com