On Tue, Nov 17, 2009 at 8:31 PM, Tres Seaver <tseaver@palladion.com> wrote: [..]
If no normalization is done, then a plain README.txt file with this info in the project itself is sufficient, or maybe making the field hold these (name, description, url) info directly.
This isn't *about* PyPI: it is about putting the information in a standard place for downstream packagers (*they* requested it). PyPI should either ignore the field or just pass it through untouched: downstream packagers are going to examine the PKG_INFO file in the tarball they work with, and might write scripts which do the mapping of the machine-readable file to their own dependency names.
And again, that's why I don't see *any* benefit of having an external registery at PyPI. You say that PyPI should ignore it, but in the meantime, the "External References Registry" implies that we will manage and maintain, urls and descriptions for each one of those Requires-External value. How this is going to work ? Why can't I put everything in my setup.py in the first place ? I have to go to PyPI first, to add an entry with an url and a description, then get back to my package to add just the name ? What happens if the name is taken, but I don't want the url and the description someone already put there ? I'll just go for another name ? And the packagers will have to look to my PKG-INFO, *and* to the PyPI registery ? That registery thing at PyPI doesn't make sense as it is currently described in the PEP because it implies that the metadata that comes with a project distribution are *incomplete* and that you need to look into a registery in some website to complete them. Although, having a structured way to describe external dependencies in the metadata is interesting. That's why I said that 100% of the information could stay in PKG-INFO (==the metadata), instead of having to maintain something else at PyPI. Developers can add their things in it, and packagers look at them. So, that means that "Require-Dist" field would need the url and the description, besides the name, like I've suggested. Tarek