On Tue, Dec 1, 2009 at 6:21 PM, Ian Bicking <i...@colorstudy.com> wrote: [...] >> >> 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 _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig