[Catalog-sig] New fields in the Metadata for PyPI
ziade.tarek at gmail.com
Wed Dec 2 22:34:38 CET 2009
On Wed, Dec 2, 2009 at 9:21 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>> I'd like to see how the PyPI UI works out. I can also imagine a more
>> extensible setup, like:
>> Project-URLs: documentation=http://myproject.org/docs/
>> mailing list=http://googlegroups.com/groups/myproject
That would be a nice solution,
> I think this also points to an important detail: are they per package,
> or per release?
> It may seem irrelevant, as it shouldn't hurt when they are per release
> (so what?) - but it does: when you change the bug tracker, will it
> retroactively also change for all past releases?
> So for the repository, mailing list, bug tracker, I think that they
> should be per project, not per release. Whether it is then useful to
> put them into PKG-INFO, I don't know.
We have raised that problem some time ago, about the "Home-page" url that
could change in a new release, but old releases would keep the
previous one in PyPI.
That led to some bugs in some installers, because they were trying to
visit dead links.
So I think a way to handle this would be to cleary state in the PEP that some
metadata are per-project, and that the newest value always overrides
any previous value.
The fields that would be eligible are:
- Project-urls (or any field we will end up adding)
> OTOH, the documentation URL often *is* per release, for many projects
> (although there might be a documentation root for the entire project,
> and a URL for the "current" documentation).
But the project always wants to display the newest urls. For example, in Python
you have links to the latest installer, and documentation, whereas old versions
are archived and can be accessed only through a specific link "Old versions".
IOW, if PyPI display only keeps the latest home page for the project,
and the latest urls,
that should be enough for all projects : they can point in their own
More information about the Catalog-SIG