On Tue, Dec 1, 2009 at 6:21 PM, Ian Bicking
Here's a proposal then, that seems to synthetize what people have been saying:
Let's drop "Repository-Browse-URL" and keep a single "Repository-URL" field, which is a free URL that can take any URL form. e.g. a browsable url, or a git/hg url etc.
I prefer Repository-Browse-URL, as it is more explicit in its use: it's a link that someone using a browser can usefully click through to. I expect it will be displayed as such on PyPI. So this link is good: http://github.com/cloudkick/libcloud
And this link is bad: git://github.com/cloudkick/libcloud.git A similar distinction exists for code.google.com projects.
Right,
Now for "Change-Log" vs "Change-Log-URL", I think the first one is better, because that's what people are already doing in their packages (when they add their changelog at the end of their long_description option), and it's not hard for PyPI to store it and display it, besides Description.
This seems fine to me. Is ReST allowed? Could one potentially just do: `Changes http://myproject.com/changes.html`_ ? And then essentially the changelog would be a single link? I'm not sure if that's a good idea. Would it be too vague to say that if the change log is a single URL that PyPI should link directly through to the change log instead of displaying the link? (The exact UI for PyPI hasn't been proposed, but if it's something like a tab with changes, that tab could actually link offsite)
The idea is to have a similar field than Description, i.e. a free text with reST allowed, so it can be potentially parsed by PyPI. Tarek