On Mar 26, 2013, at 7:50 PM, Nick Coghlan <[email protected]> wrote:
> On Wed, Mar 27, 2013 at 8:01 AM, Donald Stufft <[email protected]> wrote: >> Hopefully this will be included in .dist-info and in every package so we* >> can pretend PKF-INFO doesn't exist ;) > > The key-value format is actually easier for hand editing and covers > most cases. The extension format allows embedded JSON for more complex > cases. As an on-disk format, it's isomorphic to JSON, so I don't > actually plan to propose changing it. I disagree. - These files are used for tools to exchange data, so "hand editable" shouldn't be a primary concern. - There are a number of current fields where the current format is *not* enough and one off psuedo formats have had to be added - `Keywords: dog puppy voting election` - A list masquerading as a string, this one needs field.split() to actually parse it - `Project-URL: Bug, Issue Tracker, http://bitbucket.org/tarek/distribute/issues/` - A dictionary masquerading as a list of strings, this one needs {key.strip(): value.strip() for key, value in [x.rsplit(", ", 1) for x in field]} - Any of the fields can contain arbitrary content, previously Description had specialized handling for this which it has now been moved to the payload section, but all the same issues there affect other fields. - The Extension field name using ExtensionName/ActualKey to kludge a nested dictionary - The ExtensionName/json is a horrible kludge why are we nesting a format inside of a format instead of just using a format that supports everything we could want? As far as I can tell the only things that even use PKG-INFO is setuptools/distribute and we want to phase them out of existence anyways. The only other thing I can think of is Wheel which can either a) be updated to a different format it's new enough there's not much need to worry about legacy support or b) generate the METADATA file just for Wheels. TBH I'd like it if my name was removed as author of the PEP, I only briefly touched the versioning section and I do not agree with the decision to continue using PKG-INFO and do not want my name attached to a PEP that advocates it. > > Where we *do* need JSON-compatible metadata, though, is as an easy to > pass around in-memory data structure for use in APIs. In particular, > metadata 2.0 will be defining this format (and how to convert it > to/from the key/value format) so that the signature of the > post-install hook can be: > > def post_install_hook(installed, previous=None): > ... > > "installed" will be a string-keyed metadata dictionary for the > distribution that was just installed, containing only dicts, lists and > strings as values. > "previous" will be the metadata for the version of the distribution > that was previously installed, if any. > > Cheers, > Nick. > > P.S. And now I'm leaving for the airport to fly home to Australia - no > more replies from me for a couple of days :) > > -- > Nick Coghlan | [email protected] | Brisbane, Australia ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig
