-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 11 Dec 2004 10:22 am, Ian Bicking wrote: > Richard Jones wrote: > > On Sat, 11 Dec 2004 05:51 am, Ian Bicking wrote: > >>* Track package names into PyPI. For now these will serve as > >>identifiers for installation and dependencies. Conflicting package > >>names already cause a lot of problems anyway, so it would be nice if > >>they'd be unique. > > > > This step is done. In PyPI, a name is owned by someone (or some people). > > True. The downside is that it isn't the Python package name, it's just > a name. The Python package name seems like a natural identifier; though > some projects have no packages (e.g., many applications), and some have > multiple packages.
Ah yes - setup.py name != python package name. This has caused confusion -- some people accidentally submit packages to pypi with *their* name in the "name" field of setup.py... In CPAN (and PAUSE) there's no such disinction, IIRC. The "provides" field in metadata 1.1 solves this problem, I think. Ownership of names would flow through. > It also needs to support multiple kinds of downloads. Freshmeat has > this, though the kinds of downloads are fixed, which seems unnecessary > for us. System-specific packages are usually prefered if available. > Well, sometimes -- usually system-specific packages are harder to use > for multi-version installs. Anyway, there's a place for several kinds > of packages. How about we start with just source-url and go from there? We'll probably want some system somewhere that verifies that the source url works. Doing that at registration time might be a little too slow. > > It also removes Platform, and specifies the > > formatting of the long description field. The only open issue in that PEP > > is the license field. I believe some people would like it to remain, but > > only be used when their license doesn't appear in the Classifiers list, > > and they need to include the full text of their license (or some other > > statement about it). See PyPI bug 693471. > > > > Also of interest: > > > > Module Repository Upload Mechanism > > http://python.org/peps/pep-0243.html > > > >>* Add a field for source download; maybe make it a dictionary, so you > >>can give several links for different sources (e.g., source tarball/zip, > >>rpm, windows installer, debian package, etc). > > > > I think just sticking with the source installer is fine. This is all > > invoked by setup.py, isn't it? > > Well, by phrasing this in terms of data, not functionality, we make this > potentially frontend-neutral. We can already generate rpm's from > distutils, and I don't know why debs haven't also been added to that. > In many cases they would be preferred. Do the existing RPM / exe installers invoke setup.py to do the install? If they don't how will we fire the appropriate package database update (aka PEP 262)? > >>* Create a script that can query PyPI, get the link(s), then download > >>it. PyPI already has an XML-RPC interface, I believe. > > > > PyPI's web interface is a complete shambles. I really want to reimplement > > it in something easier to maintain, and more extensible. As an aside: the > > pypi sqlite database really needs to move to postgresql. > > Would that be hard? Is it mostly a sysadmin issue, or a coding issue? Not hard. Needs time, which I don't have. > What do you want to change in PyPI's interface? It's a hand-coded, unextensible mess. Mostly, it runs as a cgi-bin, which really needs to change to mod_python. > Well, people here at ChiPy have been showing some interest, and most of > them probably won't be going to PyCon. So people might want to try > tackling some of these things on a different schedule. And the PyCon > sprints won't be during the weekend, so that would also make it hard for > non-PyCon people to participate. OK. Mostly what's needed is a thorough design in a PEP - then just about anyone could do the small amount of coding by themselves. A PSF grant could help... Richard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBulOArGisBEHG6TARAuSqAJ9SQFALpszc8wpReashWjD0kQazegCfZnLJ Mb0AT9+IVORHtvc4L3vjBYw= =p++l -----END PGP SIGNATURE----- _______________________________________________ Catalog-sig mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/catalog-sig
