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

Nick Coghlan ncoghlan at gmail.com
Thu Jun 21 13:58:51 CEST 2012

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

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

If python-dev ends up playing referee on multiple competing PEPs, that's not necessarily a bad thing. If a consensus solution doesn't meet the needs of key parties that aren't well served by existing approaches (specifically, the scientific community, and enterprise users that want to be able to translate the plethora of language specific packaging systems to a common format for internal use to simplify system administration and configuration management and auditing), then we may as well not bother and let the status quo continue indefinitely.

Cheers, Nick.

-- Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list