factor out project metadata in PEP426?
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 suggest to rather define "project metadata" and make distribution metadata reference it. Of course we then also want a simple way to retrieve project metadata from pypi. Which could be used from tools to tell a user where to send a mail to etc. ("pypi-report-bug warehouse" could e.g. open the webbrowser with the create-issue page). Or from PyPI implementations to present proper project meta info even if looking at an older version (the project might have switched to a different repo meanwhile etc.) It would also make life easier for project maintainers to change project metadata even between releases. 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. cheers, holger
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
participants (2)
-
holger krekel
-
Nick Coghlan