<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 27, 2015 at 1:28 PM, Demian Brecht <span dir="ltr"><<a href="mailto:demianbrecht@gmail.com" target="_blank">demianbrecht@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
> On May 23, 2015, at 7:21 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
><br>
> <a href="https://www.djangopackages.com/" target="_blank">https://www.djangopackages.com/</a> covers this well for the Django<br>
> ecosystem (I actually consider it to be one of Django's killer<br>
> features, and I'm pretty sure I'm not alone in that - like<br>
> ReadTheDocs, it was a product of DjangoDash 2010).<br>
<br>
Thanks again all for the great discussion here. It seems to have taken quite a turn to a couple other points that I’ve had in the back of my mind for a while:<br>
<br>
With with integration of pip and the focus on non-standard library packages, how do we increase discoverability? If the standard library isn’t going to be a mechanism for that (and I’m not putting forward the argument that it should), adopting something like Django Packages might be tremendously beneficial. Perhaps on top of what Django Packages already has, there could be “recommended packages”. Recommended packages could go through nearly just as much of a rigorous review process as standard library adoption before being flagged, although there would be a number of barriers reduced.<br></blockquote><div><br></div><div>So there is a <a href="http://schema.org/SoftwareApplication">schema.org/SoftwareApplication</a> (or doap:Project, or seon:) Resource,</div><div>which has</div><div><br></div><div>* a unique URI (e.g. <a href="http://python.org/pypi/readme">http://python.org/pypi/readme</a>)</div><div>* JSON metadata extracted from setup.py into pydist.json (setuptools, wheel)</div><div>  - [ ] create JSON-LD @context</div><div>  - [ ] create mappings to standard schema</div><div>    * [ ] <a href="http://schema.org/SoftwareApplication">http://schema.org/SoftwareApplication</a></div><div>    * [ ] <a href="http://schema.org/SoftwareSourceCode">http://schema.org/SoftwareSourceCode</a></div><div><br></div><div>In terms of <a href="http://schema.org">schema.org</a>, a Django Packages resource has:</div><div><br></div><div>* [ ] a unique URI</div><div>* [ ] typed features (predicates with ranges)</div><div>* [ ] <a href="http://schema.org/review">http://schema.org/review</a></div><div>* [ ] <a href="http://schema.org/VoteAction">http://schema.org/VoteAction</a></div><div>* [ ] <a href="http://schema.org/LikeAction">http://schema.org/LikeAction</a></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
"Essentially, the standard library is where a library goes to die. It is appropriate for a module to be included when active development is no longer necessary.” (<a href="https://github.com/kennethreitz/requests/blob/master/docs/dev/philosophy.rst#standard-library" target="_blank">https://github.com/kennethreitz/requests/blob/master/docs/dev/philosophy.rst#standard-library</a>)<br>
<br>
This is probably a silly idea, but given the above quote and the new(er) focus on pip and distributed packages, has there been any discussion around perhaps deprecating (and entirely removing from a Python 4 release) non-builtin packages and modules? I would think that if there was a system similar to Django Packages that made discoverability/importing of packages as easy as using those in the standard library, having a distributed package model where bug fixes and releases could be done out of band with CPython releases would likely more beneficial to the end users. If there was a “recommended packages” framework, perhaps there could also be buildbots put to testing interoperability of the recommended package set.<br>
<br></blockquote><div><br></div><div>Tox is great for this (in conjunction with whichever build system: BuildBot, TravisCI)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
Also, to put the original question in this thread to rest, while I personally think that the addition of jsonschema to the standard library, whether as a top level package or perhaps splitting the json module into a package and introducing it there would be beneficial, I think that solving the distributed package discoverability is a much more interesting problem and would serve many more packages and users. Aside from that, solving that problem would have the same intended effect as integrating jsonschema into the standard library.<br></blockquote><div><br></div><div>jsonschema // JSON-LD (RDF)</div></div><br></div></div>