[Catalog-sig] Re: Meeting followup- CPAN for Python?

[Richard Jones]

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

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
  http://python.org/peps/pep-0262.html

Other relavent PEPs:

Package Index and Metadata for Distutils
  http://python.org/peps/pep-0301.html
  (*still* marked "under consideration"... sigh)
Metadata for Python Software Packages v1.1
  http://python.org/peps/pep-0314.html

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
  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?


> * 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.


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

iD8DBQFBuiErrGisBEHG6TARAn51AJwOT9hEBVKsumDM9/PBj6BbBATf/QCggmLG
Q1RxvgXOjCr67pr5H08RYDs=
=9LZy
-----END PGP SIGNATURE-----