On Thu, Jun 21, 2012 at 10:19 PM, David Cournapeau <cournape@gmail.com> wrote:
On Thu, Jun 21, 2012 at 12:58 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Thu, Jun 21, 2012 at 7:28 PM, David Cournapeau <cournape@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 | ncoghlan@gmail.com | Brisbane, Australia