[Catalog-sig] PyPI improvements

[Richard Jones]

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

On Thursday 17 Jun 2004 02:31, Ian Bicking wrote:
> Richard Jones wrote:
> > 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).
>
> I think they'd have to be parameterized in some way then -- stand-alone
> modules just aren't likely to be uniquely named.  Or, to make them
> uniquely named would lead to funky names (e.g., joe_screenscraper.py).
> Maybe it could be a name of author_username:module_name, or something
> like that.  Or maybe the names simply don't have to match the Python
> module name.

I guess the problem with modules having the same name is that people can then 
get confused about eg. *which* "csv" module you might be talking about. 
There's at least four of them out there, though one of those is in the 
stdlib.


> I really *don't* want to encourage a lot of distutiled modules with
> conflicting names.  In the comments on my post
> (http://blog.colorstudy.com/system/comments.py?u=0000001&p=P123) someone
> suggested automatically creating a zip/tarball with the proper setup.py,
> and I think that would be a bad idea and would lead to a polluted
> site-packages.

Where else would these modules be installed? Or are you advocating that they 
not be installed?


> Okay... then maybe it should be a RPC setup.  Like a client can query
> for a list of URLs that have not been archived (sufficiently), and can
> register the fact it has archived a URL.  Then there'd be the
> infrastructure so that archiving can be offloaded to another machine,
> though no archiving or mirroring would be built into the system.  There
> shouldn't be any lack of machines for the use -- disk and bandwidth is
> so cheap these days that a complex system like CPAN's seems like
> overkill.

Seems like a reasonable idea. We'd want PyPI to be able to query the archives 
it knows about on a regular (weekly?) basis just to make sure everything's in 
sync.


> I'm guessing creosote is just kind of old, and 
> (understandably) no one wants to deal with the sysadmin issues of
> upgrading.

Upgrading creosote is in the works, but it requires resources.


> I think the SF downloading should be built into the downloading client,
> as a kind of screen scraper to get to the real file.  There's so much
> stuff on SF that it can be special cased.

That's easy enough to do.


> In case of URLs, perhaps we need a (url, url_type, url_description)
> relation, where url_type is restricted, and maybe (or maybe not) (url,
> url_type) is unique.  url_type would be like homepage, documentation,
> changelog, tar.gz download, Windows installer, Mac disk image, etc.

I like this idea a lot. How it's expressed in PKG_INFO terms is another 
thing :)


> Kind of like SourceForge does for downloads, but both a bit larger, and
> a bit less explicit.  (E.g., I think SF has two different types for .gz
> and .bz2 files, which seems unnecessary.)

Yes, the sf.net types are a strange bunch.


> Statistics might be useful -- we already have the number of packages
> that are using categories (in the browse screen), but a statistic of the
> number of packages that aren't using the categories would be helpful.

I did some quickie analysis:

 http://www.mechanicalcat.net/richard/log/Python/PyPI_Categories


> An interactive setup.py-builder could be nice too -- it could help
> people get over the distutils hump, as well as promoting the necessary
> parts for PyPI submission.

Yep, this would be a great idea. My tkinter skillz are very low though. I've 
done most of my GUI programming in PyQt, and tkinter seems quite cumbersome 
in comparison :(

If I can find the time, I'd still like to have another crack at tkinter, and 
perhaps this is the kind of project I need. Unless someone else beats me to 
it :)


> >>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?
>
> In the pypi SF project.  Is that the canonical repository for the code?

Yep. I don't have a CVS change mailer set up for that cvsroot yet, as I'm the 
only committer.


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

iD8DBQFA2R8KrGisBEHG6TARAhYEAJ9AWk8XpRHKInSJvUj2la0p0iSV1wCaAg6b
/TYUhYvdIztkYRt6ACnMwIc=
=10x5
-----END PGP SIGNATURE-----