On 28 Oct 2013 06:56, "holger krekel"
Hi Nick, all,
PEP426 and its prior related peps see project-specific metadata as part of distribution metadata. Main examples are "project urls" such as "home page", "repository", "issue tracker" or contact points such as mailing lists, maintainer emails etc. However, at any point in time there is only one set of active project urls and contact points. Putting those into distribution files does not really make sense.
I think it still makes sense to include a snapshot of those details in a metadata extension, but I agree it should be easy to find out how to get more up to date project metadata from an index server. I expect to get back to metadata 2.0 related design work after 3.4b1 is out the door, using the repo at https://bitbucket.org/pypa/pypi-metadata-formats Likely changes/additions: - reserving the python.* namespace for "official" (i.e. defined in a PEP) extensions and export groups - formalising a process to give projects control over the PyPI namespaces that match their distribution names (including the current default "open access" behaviour and the ability to designate "contribution" namespaces) - rewriting the install hook system to be based on export groups and export hooks - moving anything that isn't part of the essential dependency resolution metadata into python.* extensions - defining the minimum CLI command and option requirements for setup.py (although I'd love to delegate this one to someone that either already has greater setuptools/distutils knowledge than mine, or else is willing to do the research on the currently supported command options) - resolution of the issues on the BitBucket tracker By further minimising the core, we'll be able to better assess the proposed extension mechanisms, as well as reduce the coupling between different parts of the spec (by giving the extensions their own version numbers). Another (more dubious) idea is providing a mechanism to indicate a "home" index server that is the authoritative source for namespace metadata (defaulting to PyPI). This is potentially related to the "local version numbering" redistribution problem on the issue tracker.
I feel that PEP426 is a big chance to clean up the project/distribution metadata confusion and provide a better base for future tooling and organising human communication and collaboration around Python software.
Indeed :) Cheers, Nick.
cheers, holger
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig