On 27 February 2014 10:46, Marcus Smith wrote:

that would be good. If you did, I would link to the tasks from the PUG future page.

OK, these are the things I consider blockers for an accepted metadata 2.0 spec: https://bitbucket.org/pypa/pypi-metadata-formats/issues?priority=blocker&status=open&status=new Finalising PEP 426/440/459 is on me. At this point, I think that consists of *taking away* things that aren't yet settled (specifically metadata hooks), so we can see how far this next iteration actually gets us before trying to solve the remaining problems that need some kind of trigger support. A required preliminary task is to create a revision of PEP 425 that expands its scope to also handle the parts of the file/directory naming scheme that are common across sdist, wheel and the installation database (with compatibility tags becoming a subsection), as well as fixing the definition of the compatibility tags to better handle Windows and Python 2.x binary extensions. (There's a separate non-blocker issue for better Linux/POSIX support - building from source is far more common there, and both conda and Linux distro packages remain available as a near-term workaround for the lack of upstream binary packages) The other blockers are then sdist 2.0, wheel 1.1 and a second revision of the installation database format. There are more issues in that repo, but they're ones that I don't consider *essential* as part of a usable metadata 2.0 spec - they're about things like Linux binary support, distributing full applications in addition to libraries and handling things that may require the ability to run code at installation time. Once metadata 2.0 itself is published, we can likely explore several of them as extensions before committing to anything in the core PEPs. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia