<story><title>Our Software Dependency Problem</title><url>https://research.swtch.com/deps</url></story><parent_chain><item><author>smacktoward</author><text>It&amp;#x27;s an interesting line of inquiry to think about how many of these evaluation heuristics, which are all described as things a person can do manually, could instead be built into the package manager itself to do for you automatically.&lt;p&gt;The package manager could run the package&amp;#x27;s test suite, for instance, and warn you if the tests don&amp;#x27;t all pass, or make you jump through extra hoops to install a package that doesn&amp;#x27;t have any test coverage at all. The package manager could read the source code and tell you how idiomatically it was written. The package manager could try compiling from source with warnings on and let you know if any are thrown, and compare the compiled artifacts with the ones that ship with the package to ensure that they&amp;#x27;re identical. The package manager could check the project&amp;#x27;s commit history and warn you if you&amp;#x27;re installing a package that&amp;#x27;s no longer actively maintained. The package manager could check whether the package has a history of entries in the National Vulnerability Database. The package manager could learn what licenses you will and won&amp;#x27;t accept, and automatically filter out packages that don&amp;#x27;t fit your policies. And so on.&lt;p&gt;In other words, the problem right now is that package managers are undiscriminating. To them a package is a package is a package; the universe of packages is a flat plane where all packages are treated equally. But in reality all packages &lt;i&gt;aren&amp;#x27;t&lt;/i&gt; equal. Some packages are good and others are bad, and it would be a great help to the user if the package manager could encourage discovery and reuse of the former while discouraging discovery and reuse of the latter. By taking away a little friction in some places and adding some in others, the package manager could make it easy to install good packages and hard to install bad ones.</text></item></parent_chain><comment><author>josephg</author><text>NPM (nodejs package manager) has started doing that, revealing three combined metrics for each package in the search results. It assesses every package by popularity (number of downloads), quality (a dozen or so small heuristics about how carefully the project has been created) and maintenance (whether the project is actively maintained, keeps its dependancies up to date and if it and has more closed issues than open issues on github). The idea is that when you search for a package, you can see at a glance the relative quality and popularity of the modules you&amp;#x27;re choosing between.&lt;p&gt;Its not perfect - there&amp;#x27;s no way to tell if the packages under consideration are written in a consistent style or if they have thorough unit tests, but its a clever idea. And by rating packages on these metrics they encourage a reasonable set of best practices (write a readme and a changelog, use whitelists &amp;#x2F; blacklists, close issues on github, etc). The full list of metrics is here:&lt;p&gt;&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;itnext.io&amp;#x2F;increasing-an-npm-packages-search-score-fb557f859300&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;itnext.io&amp;#x2F;increasing-an-npm-packages-search-score-fb...&lt;/a&gt;</text></comment>
<story><title>Our Software Dependency Problem</title><url>https://research.swtch.com/deps</url></story><parent_chain><item><author>smacktoward</author><text>It&amp;#x27;s an interesting line of inquiry to think about how many of these evaluation heuristics, which are all described as things a person can do manually, could instead be built into the package manager itself to do for you automatically.&lt;p&gt;The package manager could run the package&amp;#x27;s test suite, for instance, and warn you if the tests don&amp;#x27;t all pass, or make you jump through extra hoops to install a package that doesn&amp;#x27;t have any test coverage at all. The package manager could read the source code and tell you how idiomatically it was written. The package manager could try compiling from source with warnings on and let you know if any are thrown, and compare the compiled artifacts with the ones that ship with the package to ensure that they&amp;#x27;re identical. The package manager could check the project&amp;#x27;s commit history and warn you if you&amp;#x27;re installing a package that&amp;#x27;s no longer actively maintained. The package manager could check whether the package has a history of entries in the National Vulnerability Database. The package manager could learn what licenses you will and won&amp;#x27;t accept, and automatically filter out packages that don&amp;#x27;t fit your policies. And so on.&lt;p&gt;In other words, the problem right now is that package managers are undiscriminating. To them a package is a package is a package; the universe of packages is a flat plane where all packages are treated equally. But in reality all packages &lt;i&gt;aren&amp;#x27;t&lt;/i&gt; equal. Some packages are good and others are bad, and it would be a great help to the user if the package manager could encourage discovery and reuse of the former while discouraging discovery and reuse of the latter. By taking away a little friction in some places and adding some in others, the package manager could make it easy to install good packages and hard to install bad ones.</text></item></parent_chain><comment><author>DougBTX</author><text>Badges on GitHub seem to be getting more popular, a manual way to show this information in project readme files: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;badges&amp;#x2F;shields&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;badges&amp;#x2F;shields&lt;/a&gt;</text></comment>