[Catalog-sig] PyPI improvements

Richard Jones richardjones at optushome.com.au
Wed Jun 16 05:59:45 EDT 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 16 Jun 2004 14:32, Ian Bicking wrote:
> For modules this wouldn't work, as the naming would be less unique.
> Module identifiers would be an issue, but I don't think they'd
> participate in automated dependencies quite so much.

If you're going to have some meta-data embedded in the module, then one of 
those fields can be a name in the PyPI namespace.

I think that if the modules are going to be in PyPI, then they've got to have 
a unique name. Names are keys in PyPI (just as they are in CPAN / PAUSE).

> It should mostly take disk space, at least how I'm envisioning it.

Then current python.org (creosote) is definitely not up to the task.


> If 
> each package has a download URL (that's a real download URL, not just a
> web page with other references) then we cache the archives and provide
> a link to that archive if we detect that the source archive is gone.

I guess the issue is how we know what the download_url points to.

I think we agree that the distutils meta-data is going to have to grow some 
additional fields (or single a complex field) that point specifically to 
source, win32 binary, redhat RPM, etc. download files. Of course, for 
projects hosted on sourceforge, all this is moot since there is no such thing 
as a URL pointing to a file (ok, there is, but I suspect your project would 
be booted if you used URLs pointing directly at mirrors).


> > What's the "Acme" category hold? :)
>
> Joke modules, I believe.  Pythonistas apparently aren't as prone to
> humor.  So it goes.

That's what I figured. I'll take the rest of your statement in the sarcastic 
light that it was obviously intended ;)


> I've found the trove categories to be overwhelming to use when creating
> packages, and I've never paid attention to them when looking for
> packages.  In part because I can't expect authors to have defined
> categories for their package.

But they do. I've personally found the category searching to be quite 
productive a couple of times now.

Perhaps I should generate some statistics? I'd have separate counts for users 
using any categories and those using topics...


> In Perl the categories are also caught up in naming, which I don't
> think we'd use.  And you can't belong to multiple categories, for the
> same reason.  But I think they present a simpler set of categories that
> would be more useful.  The Vaults has a reasonable set of categories as
> well.  We just need less categories.

Again, the categories we have at the moment are just the combination of the 
sourceforge and freshmeat listings. I'm well aware it's not the best list 
that it could be and I'd be more than happy to work on the list. 


> I'd probably want to set up a automatic submission client that uses
> docstrings, but that's a separate issue.

I think this is a great idea (I'm a fan of lowest-possible-burden for 
contributors ;)


> The idea of broad categories (application, library, module) may
> alleviate the UI issues.

Agreed.


> We already have enough fragmentation -- even 
> the Vaults get new submissions that don't go to PyPI -- so I'd hate to
> set up an entirely separate system.

Aside: It really is a shame I got zero response from repeated enquiries about 
collaboration with the Vaults people. I honestly didn't want to have to 
develop a new system :(


> Sure, after a bit of back-and-forth here.  Maybe it would be easier to
> just write something up to be put in docs/ in CVS.

Which CVS?


    Richard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFA0BoRrGisBEHG6TARAlL+AJ0Ql/XkS7I2AyQ5GZVfBK1p7NyqegCeL5Ue
sb/rHbE3eN1uH00jd1ThGPc=
=4g4l
-----END PGP SIGNATURE-----



More information about the Catalog-sig mailing list