Request: multiple categories for libraries
How about multiple categories (i.e., tags) rather than single categories for libraries? - Conal
To be more clear, I meant my request in the context of Cabal & Hackage. I'd
like to give a comma-separated list of categories (tags) in my .cabal,
register it with Hackage, and have my package show up under each named
category in http://hackage.haskell.org/packages/archive/pkg-list.html .
- Conal
On 1/15/07, Conal Elliott
How about multiple categories (i.e., tags) rather than single categories for libraries? - Conal
On Mon, Jan 15, 2007 at 06:12:38PM -0800, Conal Elliott wrote:
To be more clear, I meant my request in the context of Cabal & Hackage. I'd like to give a comma-separated list of categories (tags) in my .cabal, register it with Hackage, and have my package show up under each named category in http://hackage.haskell.org/packages/archive/pkg-list.html .
It's already there (though undocumented), e.g. the Win32 package has category: System, Graphics but people think we need something more elaborate, see http://hackage.haskell.org/trac/hackage/wiki/HackageToDo
Ross Paterson wrote:
On Mon, Jan 15, 2007 at 06:12:38PM -0800, Conal Elliott wrote:
To be more clear, I meant my request in the context of Cabal & Hackage. I'd like to give a comma-separated list of categories (tags) in my .cabal, register it with Hackage, and have my package show up under each named category in http://hackage.haskell.org/packages/archive/pkg-list.html .
It's already there (though undocumented), e.g. the Win32 package has
category: System, Graphics
but people think we need something more elaborate, see
With the number of packages we have, I think it would be counterproductive to over-generalise with a complex tagging scheme, at least for now. With all that generality comes a lot of work: we'd have to worry about keeping our tags accurate and our tagging scheme relevant, worry about how our tags related to Debian's tags and propagate tags in both directions, develop much more complex interfaces (both web and command-line) for searching and navigating the tags, etc. etc. Also there's overlap between the facet:tag idea and the metadata we already have in Cabal packages. Why should e.g. implemented-in::Haskell be a tag, but 'extensions: FFI' be a field in the package description? I suggest if there are a few important facet-like things that we want to use to categorise packages, then we add them as fields to the package description. Cheers, Simon
On Tue, Jan 16, 2007 at 11:32:47AM +0000, Simon Marlow wrote:
With the number of packages we have, I think it would be counterproductive to over-generalise with a complex tagging scheme, at least for now. With all that generality comes a lot of work: we'd have to worry about keeping our tags accurate and our tagging scheme relevant, worry about how our tags related to Debian's tags and propagate tags in both directions, develop much more complex interfaces (both web and command-line) for searching and navigating the tags, etc. etc.
In that case, we ought to agree a set of categories, based on the purpose/use of packages.
participants (3)
-
Conal Elliott -
Ross Paterson -
Simon Marlow