[Catalog-sig] Adding trove categories
ianb at colorstudy.com
Thu Mar 2 21:54:23 CET 2006
On Mar 1, 2006, at 11:59 PM, Richard Jones wrote:
> On Thursday 02 March 2006 07:22, Ian Bicking wrote:
>> We want to add Cheese Shop categories for frameworks, so people can
>> register things.
>> These are the ones we (Kevin and I) would like:
>> Framework :: Paste
>> Framework :: TurboGears
>> Framework :: TurboGears :: Widgets
>> Framework :: TruboGears :: Applications
>> Topic :: Internet :: WWW/HTTP :: WSGI
>> Topic :: Internet :: WWW/HTTP :: WSGI :: Application
>> Topic :: Internet :: WWW/HTTP :: WSGI :: Server
>> Topic :: Internet :: WWW/HTTP :: WSGI :: Middleware
> Hurm. At the moment there's no top-level "Framework" grouping in the
> stuff. I'm not sure what will happen if one is added. I (or someone
> else who
> possibly has more time) will need to test things out to make sure it
> fall about laughing.
As I remember the trove categories were a pretty simple entry in the
database, just a flat list of strings.
>> That's just the ones we want, and we have packages that could go in
>> there right now. I'm not that happy about putting WSGI under Topic ::
>> ..., but it's not really a "Framework" either. Though putting it
>> framework would be okay too.
> Er, I assume that means you'd prefer it to be under Topic, or do you
> not care.
> I'd prefer that you make the call, to be honest.
> Would "Topic :: Internet :: WWW/HTTP :: Framework :: ..." be too
Yes, that would be too cumbersome; we just happen to be web frameworks.
Other frameworks might want a place in there too. "Framework" being a
classifier for actually-interesting-to-Python-users categories ;)
Right now the trove categories don't make much sense for Python
projects; lots of cruft, little granularity around things we actually
And "Topic :: Internet :: WWW/HTTP" is a super-lame category anyway ;)
It should be "Topic :: Web". But eh... really, the whole hierarchy and
taxonomy of packages is stupid. Which is why I would just like a
fairly flat list of "frameworks", which are Python projects for which
there exist packages that extend or utilize the framework.
> Currently under "WWW/HTTP" we have:
> Topic :: Internet :: WWW/HTTP :: Browsers
> Topic :: Internet :: WWW/HTTP :: Dynamic Content
> Topic :: Internet :: WWW/HTTP :: Dynamic Content :: CGI
> Topic :: Internet :: WWW/HTTP :: Dynamic Content :: Message Boards
> Topic :: Internet :: WWW/HTTP :: Dynamic Content :: News/Diary
> Topic :: Internet :: WWW/HTTP :: Dynamic Content :: Page Counters
> Topic :: Internet :: WWW/HTTP :: HTTP Servers
> Topic :: Internet :: WWW/HTTP :: Indexing/Search
> Topic :: Internet :: WWW/HTTP :: Site Management
> Topic :: Internet :: WWW/HTTP :: Site Management :: Link Checking
> Consider browsing - I'd think that people are more likely to go into
> WWW/HTTP topic to discover web stuff than a separate top-level
The top-level framework group is actually something I expect projects
will be linking directly into. So Paste will have a link to its
category, TurboGears to its, and so on; the XMLRPC interface offering
some additional opportunities. Or maybe with RSS extensions, e.g.,
putting a filtered aggregator on a website.
Mostly I don't want projects to have to implement their own package
indexes. If for no other reason than that it is a big waste of time
for those projects when we already have an index. But projects need a
way of providing a selective view of the index.
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
More information about the Catalog-sig