[Catalog-sig] New proposal, with PEP

[Richard Jones]

On Sun, 27 Oct 2002 5:37 am, Martin v. Loewis wrote:
> Richard Jones <rjones@ekit-inc.com> writes:
> > Note that I continued on to say that I have not given up. Just that some
> > feedback (either positive, negative _or_ ambivalent) would be nice.
>
> Ok, so here's my negative feedback:
>
> Why would anybody want to use such a thing? As long as it contains
> only a few dozen packages,  I really don't see a need.
>
> To make it larger, I think it must accommodate a wider range of
> packages, not just those that get installed through distutils.

It's trivial to provide a form interface to manually submit package 
information. I will do so now.


>  But if
> that is the way to go, how is this different from the Vaults, or
> Freshmeat? If I were to look for Python packages, I'd look at

Because:

1. there's no integration with distutils, and consequently no one-shot, 
trivial mechanism for submitting metadata,
2. neither of the above are hosted at python.org, and hence don't have any of 
the legitemacy that that hosting would bring, and
3. Freshmeat is a pain to use, and only supports open-source Linux projects 
(or at a minimum open-source projects that are available on Linux).


> > It's not in operation at python.org though, which I see as being
> > important to its acceptance. I don't have any control over
> > that. Hence the PEP. Ongoing support would be minimal, and I'd be
> > gladly putting my hand up to take on that job, assuming I can have
> > access to the machine python.org is hosted on.
>
> I'd be happy to install it on python.org, just give me instructions
> (in private email).

Installation on python.org can wait until I've finished the code, but thanks 
for the offer! It's good to know that if this is accepted then the python.org 
step is possible :)


> > 1. the web interface installed on python.org, and either someone there to
> >    look after it or access so I can look after it,
>
> I can certainly help here.
>
> > 2. the "register" command included in the next non-patch python
> > distribution (ie. 2.3), and
>
> That will be difficult; you need to propose it on python-dev.

Hence the PEP. I _think_ I'm following correct procedure here...


> For the time being, you should find a means to do without.

The "register" command could almost be considered the most important component 
of this proposal, making it trivial for people to submit information to the 
central index.


> > 3. optionally have the distutils metadata expanded to include Trove
> >    discriminators
>
> That will be really hard, I guess - people won't see the need to add
> this to their setup calls.

People will add it when they want their package to be easier to find. One of 
the features I've built into the specification is the notion of updating the 
metadata - so if they want to add in a longer description at a later date, 
they can just edit their setup and re-invoke the register command. Same thing 
with adding or editing the trove discriminators.


> It would also cause the packages to break
> on older distutils installations.

That's a problem, yes. I'm not sure what the solution would be. Older packages 
run with the new code wouldn't have a problem. Newer packages run with older 
code will break on the "trove" keyword argument to setup(). I'm not sure what 
the solution would be.


     Richard