The feedback I have received (both on-list and in response to some off-list queries to specific people) tells me that PEP 426 isn't quite ready for acceptance yet. Things I'll be working on or facilitating over the next few weeks: - documenting an overall transition plan to put the new metadata format in context - clear acceptance criteria in PEP 426, primarily a list of specific projects and individuals that I have requested endorsement from before I am willing to accept the PEP - adding entry-points to PEP 426 - some more adjustments to PEP 426 for improved pkg_resources compatibility - some adjustments to PEP 426 for easier translation to JSON-compatible structured data - PEP for a standardised approach to metadata caching in installation databases - draft PEP for adding distlib to Python 3.4 - draft PEP for automated conversion of PEP 426 metadata files to JSON-compatible structured data This postpone does mean the initial wheel rollout in various projects will be based on metadata 1.2 + the Provides-Extra field (and associated environment marker change), rather than being cleanly based on metadata 2.0. I can live with that - that part of the PEP is *not* open to change, but there are other legitimate concerns that need to be addressed before I declare the PEP accepted. Regards, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4