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

Richard Jones richardjones at optushome.com.au
Sat Dec 11 23:33:54 CET 2004

Hash: SHA1

On Sat, 11 Dec 2004 04:55 pm, Ian Bicking wrote:
> Richard Jones wrote:
> > On Sat, 11 Dec 2004 10:22 am, Ian Bicking wrote:
> >>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?
> A dictionary seems like such a simple extension, and multiple download
> links are useful for a good many packages already.  The keys would just
> be strings, "windows-installer", "rpm", "source".

We should probably use the same names as the distutils dist command.

> > 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.
> OK, internally I guess there should be a flag "not-checked", "working",
> "broken".  Later if we do backups we could use this to signal when we
> need to replace the link with the backup link.


> Or to... WSGI!  It'd probably be a smoother transition than mod_python,
> since WSGI looks a lot like cgi.  That's something I might find
> interesting to try.  Well... this is also a distraction from my own
> projects; it's always a difficulty with these things for me.  I'm sure
> you know the feeling.


I'll look into WSGI.

> So... one underlying motivation is getting some of the other people at
> ChiPy involved; there was a lot of discussion about this, and people
> following up on that discussion.  It seems like a good project.
> Looking at the code, it looks like simply moving HTML out to templates
> would help quite a bit.  Then moving to Postgres, which would probably
> be easy enough.  Well, this is the bread and butter of my day work, so
> it seems easy enough to me... I'm not sure what other people feel.  Has
> anyone else checked out pypi and given it a look?  To checkout:
> cvs -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/pypi login
> cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/pypi co pypi
> Then to get it started...
> I made a directory /tmp/pypi, and copied config.ini into it, editing it
> a bit.  I made sure pypi.cgi was available through Apache.  It may take
> some configuration to get .cgi files to be run for you.  I had to make
> sure the directory the database was located in was writable by the web
> server.
> Lastly, it would be useful to have a full database available.  Is there
> a place we can pick up a dump of the pypi database?  It doesn't have to
> be very fresh.

Snarfed just now from creosote:


(874 Kb)

> > 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...
> What portions do you think need PEPs?  The internal design of PyPI
> doesn't seem to be a PEP concern.  The added metadata is a PEP concern,
> I guess.

I guess there's a bunch of individual PEPs at the moment. They need review by 
both yourself and me (I've read them, but not with an eye to review / 

The method you're describing to download and install using a PyPI-supplied URL 
would be an extension to distutils in the Python core, and should be done as 
a PEP to allow community scrutiny of the approach. That PEP would also be a 
good place to capture feedback and address issues of security (eg. "we don't 
address security issues").

Also, there's no real sense of a greater strategy, which is what we're 
discussing in these emails. I don't know whether that's a new PEP, or just a 
document somewhere that describes how all these disparate parts form a 
cohesive whole.

Version: GnuPG v1.2.4 (GNU/Linux)


More information about the Catalog-sig mailing list