Andrew Barnert writes:
If a maintainer (obvious extension: 3rd party recommendations and voting) wants to recommend other packages that work and play well with her package but aren't essential to its function, how about a dictionary mapping Trove classifiers to lists of recommended packages for that implmenentation?
This is a really cool idea, but it would help to have some specific examples.
For example, BeautifulSoup can only use html5lib or lxml as optional HTML parsers, and lxml as an optional XML parser; nothing else will do any good. But it works well with any HTTP request engine, so any "global" recommendation is a good idea, so it should get the same list (say, requests, urllib3, grequests, pycurl) as any other project that wants to suggest an HTTP request engine. And as for scraper frameworks, that should look at the global recommendations, but restricted to the ones that use, or can use, BeautifulSoup. I'm not sure how to reasonably represent all three of those things in a node.
Well, #2 is easy. You just have a special "global" node that has the same kind of classifier->package map, and link to that. I don't think #3 can be handled so easily, and probably it's not really worth it complexifying things that far at first -- I think you probably need most of SQL to express such constraints. I suspect that I would handle #3 with a special sort of "group" package, that just requires certain classifiers and then recommends implementations of them that work well together. It would be easy for the database to automatically update a group's recommended implementations to point to the group (which would be yet another new attribute for the package). I'll take a look at the whole shebang and see if I can come up with something a bit more elegant than the crockery of adhoc-ery above, but it will be at least next week before I have anything to say. Steve