CPAN functionality for python - requirements

[Bruce Sass]

On Tue, 27 Feb 2001, Doug Hellmann wrote:
> 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)
<...>
> I'm not sure why the "what do you have" question is needed.  The "send me
> that(mandrake.rpm)" interaction is what we want.

Automated tools need to query what is available so they can decide
where to satisfy a dependency from.  Packages will be available from a
variety of outlets, not just the python archive.

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

Yup.  What do you think of having the server look like a platform
specific distribution archive?  So, when the server sees requests for
(lets say) Debian style Packages and Release files (used to create the
available packages DB), it assembles them from the list of python
packages.  Requests for URLs that look like those of packages in RHs
archive whould result in a RH-rpm being served up.  This would allow
for complete integration with any client's native package archive
system the server knows about, and give the CPyAn archive full control
over package names, release numbers, etc. - the little bits that can
cause simple to fix, but annoying, dependency problems.
just a thought

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

There could also be an (all) format, why limit the possibilities.

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

Obviuosly there is nothing that can be done about normal system
logging, but the cgi/factory-object/whatever should not keep any
persistent user/connection information around (i.e., no log from the
CPyAN software which lists who got what in which format when).


- Bruce