[Distutils] PEP 345 - 3 new fields

[Tarek Ziadé]

On Tue, Dec 1, 2009 at 6:21 PM, Ian Bicking <ianb at 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