[Catalog-sig] PyPI enhancement doc
"Martin v. Löwis"
martin at v.loewis.de
Wed May 25 23:23:37 CEST 2005
Ian Bicking wrote:
> The ``packagetype`` column has no particular type or constraint. I
> suggest that it contain these types taken from ``distutils``:
I see. I hadn't understood this earlier - documenting that seems
fine to me.
> The binary distributions are all potentially platform specific, but
> (except for Windows) the platform isn't encoded into the packagetype.
> Should packagetype be extended to include information like Python
It was excluded because it can be implied from the package file
(distutils makes sure the filenames don't conflict). upload.py
puts the platform in the comment.
Standardizing on platform names is a tricky issue: Is "SuSE" the
same platform as "Debian"? Is it the same platform as "SuSE Linux"?
> Another change would be to refactor the database, so that
> release_files didn't have python_version, packagetype, or md5_digest
> fields, but rather a third table (referenced by both release_files and
> package_urls) reference this package-metadata field.
What would be the advantage of doing so? If it is normalization:
I don't see any advantage in normalization at all.
> XML-RPC methods
> This is an initial list of proposed methods for PyPI to support:
I think this whole thing is highly debatable. Why XML-RPC? Are HTML
forms not good enough for you? Why not CORBA? etc.
It appears to be a design principle of PyPI to not use XML-RPC if
it can be avoided. I don't know where that principle comes from,
but I think it needs to be followed if indeed it is a principle.
If there is no such principle, I think all the current forms should
be duplicated to simplify the code in the distutils commands.
> Search should be available with a single field, that searches all of
> package name, summary, description/description_html, keywords. This
> should be on the front page.
In general, details of the UI and the database can be easily
integrated as long as they don't affect current users and
as long as they don't affect distutils or other programmatic
So contributions are welcome, although I understand this is
meant to be solved by Postgres full text search.
> There should be a contact form attached to each package that will be
> emailed to any people on record as owners or maintainers, for
> reporting bad or missing links or other incorrect data.
Again, contributions are welcome. We should be careful not to implement
another issue tracker here, though, so just sending an email might be
enough for the moment (or else a read-only roundup installation,
writable only to PyPI and the maintainer might be the right solution).
As soon as tracking is available, people will start using it to
report bugs on the actual software itself, which might defeat
the bug reporting channels the maintainers try to establish.
So perhaps a "report problems with this record to" field might
be sufficient, with the feedback form only available if the field
is not filled.
In any case, if you have something that works, please submit
a patch to sf.net/projects/pypi.
More information about the Catalog-sig