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 | [EMAIL PROTECTED] | http://blog.ianbicking.org _______________________________________________ Catalog-sig mailing list Catalog-sig@python.org http://mail.python.org/mailman/listinfo/catalog-sig
