[Python-ideas] Increasing public package discoverability (was: Adding jsonschema to the standard library)

[Wes Turner]

On Wed, May 27, 2015 at 1:28 PM, Demian Brecht <demianbrecht at gmail.com>
wrote:

>
> > On May 23, 2015, at 7:21 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> >
> > https://www.djangopackages.com/ covers this well for the Django
> > ecosystem (I actually consider it to be one of Django's killer
> > features, and I'm pretty sure I'm not alone in that - like
> > ReadTheDocs, it was a product of DjangoDash 2010).
>
> 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:
>
> 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.
>

So there is a schema.org/SoftwareApplication (or doap:Project, or seon:)
Resource,
which has

* a unique URI (e.g. http://python.org/pypi/readme)
* JSON metadata extracted from setup.py into pydist.json (setuptools, wheel)
  - [ ] create JSON-LD @context
  - [ ] create mappings to standard schema
    * [ ] http://schema.org/SoftwareApplication
    * [ ] http://schema.org/SoftwareSourceCode

In terms of schema.org, a Django Packages resource has:

* [ ] a unique URI
* [ ] typed features (predicates with ranges)
* [ ] http://schema.org/review
* [ ] http://schema.org/VoteAction
* [ ] http://schema.org/LikeAction


>
> "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.” (
> https://github.com/kennethreitz/requests/blob/master/docs/dev/philosophy.rst#standard-library
> )
>
> 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.
>
>
Tox is great for this (in conjunction with whichever build system:
BuildBot, TravisCI)



>
>
> 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.
>

jsonschema // JSON-LD (RDF)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150527/1e70574e/attachment-0001.html>