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

[Richard Jones]

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