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

[Wes Turner]

On Thu, May 28, 2015 at 9:34 AM, Skip Montanaro <skip.montanaro at gmail.com>
wrote:

> On Wed, May 27, 2015 at 2:03 PM, Donald Stufft <donald at stufft.io> wrote:
> > I’m of the opinion that, given a brand new language, it makes more sense
> to have really good packaging tools built in, but not to have a standard
> library.
>
> While perhaps nice in theory, the process of getting a package into
> the standard library provides a number of filters (hurdles, if you
> will) through which a package much pass (or surmount) before it is
> deemed suitable for broad availability by default to users, and for
> support by the core development team. Today, that includes
> documentation, unit tests, broad acceptance by the user community (in
> many cases), and a commitment by the core development team to maintain
> the package for the foreseeable future. To the best of my knowledge,
> none of those filters apply to PyPI-cataloged packages. That is not to
> say that the current process doesn't have its problems. Some really
> useful stuff is surely not available in the core. If the core
> development team was stacked with people who program numeric
> applications for a living, perhaps numpy or something similar would be
> in the core today.
>
> The other end of the spectrum is Perl. It has been more than a decade
> since I did any Perl programming, and even then, not much, but I still
> remember how confused I was trying to choose a package to manipulate
> dates and times from CPAN with no guidance. I know PyPI has a weight
> field. I just went back and reread the footnote describing it, but I
> really have no idea how it operates. I'm sure someone nefarious could
> game that system so their security compromising package drifts toward
> the top of the list. Try searching for "xml." 2208 packages are
> return, with weights ranging from 1 to 9. 107 packages have weights of
> 8 or 9. If the standard library is to dwindle down to next-to-nothing,
> a better scheme for package selection/recommendation will have to be
> developed.
>

A workflow for building CI-able, vendorable packages with coverage
and fuzzing?

* xUnit XML test results
* http://schema.org/AssessAction
  * Quality 1 (Use Cases n, m)
  * Quality 2 (Use cases x, y)
  * SecurityAssessAction
* http://schema.org/ChooseAction
  * Why am I downloading duplicate functionality?

* http://schema.org/LikeAction
  * Community feedback is always helpful.

Or, a workflow for maintaining a *distribution of* **versions of** (C and)
Python packages?


> Skip
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150528/f40ca00b/attachment.html>