CPAN functionality for python - requirements

[Doug Hellmann]

On Tue, 27 Feb 2001, Bruce Sass wrote:
> I'm a little concerned about the privacy aspect of this...
> 
> > That decision is up to the client.  If the client has the smarts to turn
> > a distutils package into an RPM, then the client would list it's preferred
> > format as a distutils package and it would handle the rest.  If it can't,
> > you can either select an RPM, or fall back to a distutils package.
> 
> Why should the client need to "list" anything.
> 
> client: what do you have?
> server: this(deb,rh-5.rpm,rh-6.2.rpm,rh-7.rpm) that() other(hqx)
> client: send me this(deb), that(mandrake.rpm), other()
> server: sorry don't have that(mandrake.rpm)
> client: send me that(deb)
> server: sorry don't have that(deb)
> client: send me that()

I'm not sure why the "what do you have" question is needed.  The "send me
that(mandrake.rpm)" interaction is what we want.

The client requests packages in the formats prefered.  A standard source format
should be available for all packages so that everybody can get every package in
some form.  If the standard source format contains distutil-enabled scripts,
platform specific distribution files could be generated from the source.

> In other words... the server is just that - a server - it does not ask
> questions, it does not keep track of any preferences, it serves up
> files.

No, of course not.

> This could work...
> client: only show me (deb) and ()
> client: what do you have?

Right, that would be a bit more efficient than specifying a format for every
package for every request.

> The server should NOT be usable as a tool to track Python users and
> their habits, and making it do so should require a conscious effort on
> the operators part (so there is no opportunity for the operator to
> say, "I don't track you, that's just how the software works").

The server is likely to be a cgi, which by its nature means requests may be
written to a log file.  Should that be disallowed?

Doug