[Catalog-sig] Re: Meeting followup- CPAN for Python?
richardjones at optushome.com.au
Sat Dec 11 23:33:54 CET 2004
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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:
> > 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the Catalog-sig