On Thu, Jun 21, 2012 at 10:19 PM, David Cournapeau <courn...@gmail.com> wrote:
>
>
> On Thu, Jun 21, 2012 at 12:58 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
>>
>> On Thu, Jun 21, 2012 at 7:28 PM, David Cournapeau <courn...@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 | ncogh...@gmail.com | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
