On Sat, Apr 11, 2015 at 12:29 PM, Marc Abramowitz <msabr...@gmail.com> wrote:
> Interesting. One of the things that would help with getting people to help > and is in the PEPs but last I checked wasn't yet implemented is the > metadata that allows putting in all kinds of URLs and the ones I'm > primarily thinking of here are the source code repository URL and the issue > tracker URL. > http://legacy.python.org/dev/peps/pep-0459/: PEP:459Title:Standard Metadata Extensions for Python Software Packages Version:471651c1fe20Last-Modified:2014-07-02 22:55:34 -0700 (Wed, 02 Jul 2014) <http://hg.python.org/peps/file/tip/pep-0459.txt>Author:Nick Coghlan <ncoghlan at gmail.com>BDFL-Delegate:Nick Coghlan <ncogh...@gmail.com> Discussions-To:Distutils SIG <distutils-sig at python.org <distutils-sig@python.org?subject=PEP%20459>>Status:DraftType:Standards TrackContent-Type:text/x-rst <http://legacy.python.org/dev/peps/pep-0012> Requires:426 <http://legacy.python.org/dev/peps/pep-0426>Created:11 Nov 2013 Post-History:21 Dec 2013 A JSON-LD context would be outstanding. - [ ] Additional properties for {...} (see RDFJS https://text.allmende.io/p/rdfjs ## Tools Schema) > I personally sigh when I see a PyPI page that lists its URL as said PyPI > page as this seems redundant and not useful and I'd rather see a GitHub or > Bitbucket URL (or maybe a foo-project.org or readthedocs URL, but I the > repo URL is usually what I'm most interested in). > > If we had the metadata with all the different kinds of URLs and the tools > to show it and search it, then it would be clearer what to put where and > would make it easier for consumers to find what they're looking for. > > Another thought I had while reading your email was the OpenHatch project > and if there could be some tie-in with that. > > It also would be interesting if package maintainers had a channel to > communicate with their user base. Back when I was at Yahoo, our proprietary > package tool kept track of all installs of packages and stored the > information in a centralized database. As a result, a package maintainer > could see how many people had installed each version of their package and > could send emails to folks who had installed a particular version or folks > who had installed any version. A lot of folks used this to warn user bases > about security issues, bugs, deprecations, etc. and to encourage folks to > upgrade to newer versions and monitor the progress of such efforts. > Links to e.g. cvedetails, lists, and RSS feeds would be super helpful. Links to e.g. IRC, Slack, Gitter would be super helpful. Where Links == {edges, predicates, new metadata properties} > > This is a pretty big architectural change of course. I can imagine an > easier route could be to have the metadata have a link to a mailing list so > a user could easily check a box, press a button, specify an option to pip > install, etc. that would subscribe them to a project mailing list, hosted > elsewhere. This obviates the need for PyPI/Warehouse to have a big database > of who is interested in what by distributing out that responsibility to > other tools like Mailman and what not. > There are a number of web-based pip management applications. Really, upgrading to Mailman 3 w/ the message archive links auto-appended would also be great. The applications are much broader than just Python packages (eggs, wheels, condabuilds) and pip/peep dependency resolution. (... RDFJS https://text.allmende.io/p/rdfjs ## Tools Schema )
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
