[Catalog-sig] Re: Meeting followup- CPAN for Python?
richardjones at optushome.com.au
Fri Dec 10 23:20:17 CET 2004
-----BEGIN PGP SIGNED MESSAGE-----
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).
> * Add a field for package dependencies, based on those names. Forget
> about version requirements for now. Though in theory, since distutil
> setup.py files are just Python scripts, this should be extensible.
Also, handling versioning implies that people retain versioned source
downloads - something we can't rely on.
Possibly what we need is for the package to be able to indicate which versions
it's been *tested* with, so it can warn that the download might not work?
IIRC a problem with CPAN was version incompatibilities breaking things (I
know I've hosed my Perl install a couple of times)
Now, having dependencies list is all well and good - what do we do with them?
If we have automated checking against those dependencies, then that implies
that we remember what's installed. AMK has done some work on this:
Database of Installed Python Packages
Other relavent PEPs:
Package Index and Metadata for Distutils
(*still* marked "under consideration"... sigh)
Metadata for Python Software Packages v1.1
Metadata version 1.1 has fields for "download-url", "requires", "provides",
"obsoletes" and "conflicts". I guess we need to change "download-url" to
"source-url". Mmm. Ambiguity. 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
> * 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?
> * 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.
> Because of SF,
> the downloader has to be a little smart about the load balancing page in
> that case, but that's relatively easy.
We'll be special-casing for them, but there will probably be other download
sites like this :(
> Well, these are some of my ideas. If people are interested in this in
> general, we could try to organize a little mini-sprint; a number of us
> would come together and try to bang it out. We could try to schedule
> and coordinate this with Richard or other interested people over IRC.
Looks like I'll be attending PyCon, so a sprint there would be possible.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Catalog-sig