[Catalog-sig] Adding trove categories

[Ian Bicking]

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 
> Trove
> 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 
> won't
> 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 
>> under
>> 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 
> cubmersome?

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

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 
> Tools/Libraries
>  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 
> the
> WWW/HTTP topic to discover web stuff than a separate top-level 
> Framework
> grouping.

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