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

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


-----BEGIN PGP SIGNED MESSAGE-----
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.

Yup.


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

 http://www.mechanicalcat.net/temp/pkgbase.db.bz2

(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 / 
implementation).

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.


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

iD8DBQFBu3XWrGisBEHG6TARAvxWAJ4n54VcFhbo3/Q72jc+nNJ8HKcy+QCeKdWM
t7+j2JxWbLSRE++MZvZDduw=
=7XNZ
-----END PGP SIGNATURE-----


More information about the Catalog-sig mailing list