On 30 March 2016 at 06:51, Michael Selik
In days of yore, before package managers, people used to download source code and read it. Maybe not all of it, but enough to feel not terribly scared when running that code. In modern times, with centralized package repositories and convenient installer tools, we want a better way to know "what’s the right package to use for this task?" It's a "first-world problem" in a sense. There are too many products in my supermarket aisle! On a personal note, I have on occasion spent twenty minutes choosing a toothpaste at Target.
If I care enough, I'll take a moment to look at how many downloads have been counted recently, how many issues there are (usually on GitHub), how many contributors, etc. I'll read the docs. I might even poke around in the source. I'll also check Google rankings to see if people are chatting about the module and linking to it.
I'm not sure if there's a good centralized solution to this problem, but it's a question many people are asking: How do I know which non-stdlib module to use?
Back at Georgia Tech, my professor [0] once told me that the way to get rich is to invent an index. He was referring to Richard Florida's "Creative Class" book and the subsequent "Creativity Index" consulting that Florida provided to various municipalities. People who score high on the index pay you to speak. People who score low on the index pay you to consult.
There are a few companies who sell a Python package reputation service, along with some distribution tools. Continuum's Anaconda, Enthought's Canopy, and ActiveState's ActivePython come to mind. There's clearly value in helping people answer this question.
And so do Linux distributions. There's a reason there are so many of the latter: "good" choices depend a great deal on what you're doing, which means there's no point in trying to come up with the "one true reputation system" for software components. djangopackages.com does a relatively good job for the Django ecosystem, but the simple fact of using Django puts you far enough down the path towards solving a particular kind of problem (web service design with a rich user permission system backed by a relational database) that a community driven rating system can work. By contrast, I think Python itself covers too many domains for a common rating system to be feasible - "good for education" is not the same as "good for sysadmin tasks" is not the same as "good for data analysis" is not the same as "good for network service development", etc. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia