More "about" metadata

conda-build now allows more metadata in the about section. We should start making use of it where appropriate.

ref: https://github.com/conda/conda-build/pull/831

In particular we now have:

'home', 'dev_url', 'doc_url', 'license_url', # these are URLs
'license', 'summary', 'description', 'license_family', # text
'license_file', 'readme'

[goanpeca]

Same here, I dont think there is such a policy to enforce that LICENSE, cause some project simply dont include it and we would need to wait for a new version UPSTREAM. I would say license_file should be completely optional if it is not located on tha base of the repo.

[jankatins]

However, and here is my main concern, conda-forge is not a Linux community! See how small and technical they are. Do we want to be more like PyPI or more like Debian?

I think “accessible to a newcomer” and “technical sound” should be two different dimension (which may influence each other).

PS: I am a packager for OpenSUSE and there are many rules there I would never apply here because that would make conda-forge a niche package distributor instead a robust multi-platform and community accessible one 😉

In my opinion the “rules” make for a “robust multi-platform” distribution. E.g. it is my believe that debian is a good technical platform because of the debian policy with it’s encoded knowledge and learnings and the strict enforcement of these documents.

So to make a up a different “bad case scenario”: if there is only a limited set of loose rules, the packages will not play well with each other, resulting in many incompatibilities, resulting in users running away screaming.

To give an example where IMO “more rules” make for a better technical platform: I still think the current “policy” of “pinning” native libs will not scale because currently the knowledge of what works together with what is codified in a script (which will grow horrible if all the libs from a normal unix distribution gets added), most of the pins rely on semver versioning rules (which are not true for all of the libs) and it will blow up each time a real incompatibility is encountered (because it needs a rebuild of all dependent packages). The solution is IMO adding rules to specify the naming of packages (=versioned), splitting packages (multiple packages for header vs libs), how to specify dependencies on what in the dependent packages and so on. This can all get technical solutions (like debian and probably every other linux distribution already has), but basically these are “only” technical implementation of a set of rules which work.

Unfortunately the linter right now is binary it either passes or fails. lintian the linter for debian packages has a more finegrained result: it can both tell you the “badness” of something and also how sure the linter is that this is really a problem. So if the linter could tell one “this recipe would benefit from a description” but not fail the the recipe (or only once add a whishlist bug to the repo), then this is IMO fine.