[Catalog-sig] PyPI improvements
richardjones at optushome.com.au
Wed Jun 23 02:11:22 EDT 2004
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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
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
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
> I'm guessing creosote is just kind of old, and
> (understandably) no one wants to deal with the sysadmin issues of
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
> 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:
> 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
> >>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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Catalog-sig