[Distutils] pip/warehouse feature idea: "help needed"

Donald Stufft donald at stufft.io
Tue Apr 14 04:13:21 CEST 2015

> On Apr 13, 2015, at 8:57 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
> Nick Coghlan <ncoghlan at gmail.com> writes:
>> On 11 Apr 2015 12:22, "Alexander Walters" <tritium-list at sdamon.com> wrote:
>>> Is the package index really the best place to put this? This is a
>>> very social-networking feature for the authoritative repository of
>>> just about all the third party module, and it feels like either it
>>> could corrupt the 'sanctity' of the repository (in the absolute
>>> worst case)
>> If you're concerned that this feature might weaken the comforting
>> illusion that PyPI published software is contributed and maintained by
>> faceless automatons rather than living, breathing human beings, then
>> yes, encouraging folks to think more about where the software they use
>> is coming from would be a large part of the point of adding such a
>> feature.
> I can't speak for Alexander, but I'm also −1 to have this *on PyPI*.
> I'm all for such features existing. What is at issue is whether PyPI is
> the place to put them.
> We have been gradually improving the function of PyPI as an
> authoritative *index* of packages; that's possible because it is a
> repository of uncontroversial facts, not opinions (i.e. “what is the
> packaging metadata of this distribution”, “where is its documentation”,
> “where is its VCS”, etc.).
>>> I am not saying the PSF shouldn't do this, but is pypi REALLY the
>>> best part of python.org to put it?
>> I personally believe so, yes - sustaining software over the long term is
>> expensive in people's time, but it's often something we take for granted.
>> The specific example Guido brought up in his keynote was the challenge of
>> communicating a project's openness to Python 3 porting assistance.
> The people doing the work of maintaining PyPI have said many times in
> recent years that there just isn't enough person-power to add a whole
> bunch of features that have been requested. Why would we think
> moderating a social-networking rating, opinion, discussion, or other
> non-factual database is something reasonable to ask of the PyPI
> maintainers?
> Conversely, if we are under the impression that adding ratings,
> feedback, reviews, discussion, and other features to PyPI is *not* going
> to be a massive increase in workload for the maintainers, I think that's
> a foolish delusion which will be quite costly to the reputation PyPI has
> recently gained through hard effort to clarify its role.
> By all means, set up a well-maintained social ecosystem around Python
> packages. But not on PyPI itself: The Python Package Index is feasible
> in part because it has a clear and simple job, though, and that's not
> it.
> --
> \                “If you can't hear me sometimes, it's because I'm in |
>  `\                                      parentheses.” —Steven Wright |
> _o__)                                                                  |
> Ben Finney
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig

I don’t see any problem with the general idea of adding features to PyPI to
enable package maintainers to find more help maintaining specific parts of
their projects. I do have a problem with expecting the PyPI administrators
to fill out or otherwise populate this information. Saying “Here’s a place
you can donate to me” is still a fact, it’s just a more social fact than
what we currently enable.

I’m kind of down on the idea of linking to CVs or linkedin as part of the
project metadata because that’s not project specific and is really more
maintainer specific. I think that particular feature would be better suited
to some sort of global “Python profile” that could then be linked to from
PyPI instead of trying to bake it into PyPI itself.

However things like “Looking for New Maintainers / Orphan a Project”,
or some call to actions on “here are some issues that need fixed” or other
things doesn’t seem unreasonable to me. Particularly the ability to orphan
a project or look for new maintainers seems like a useful thing to me that
really can’t live anywhere other than PyPI reasonably.

The other items can live elsewhere if we wanted them to since they would be
easy to add to the long_description of a project which would get added to
the PyPI page but that has some drawbacks. For things like crowdfunding campaigns
the long_description is set when you upload a release, however it’d be useful
to have the campaigns update as the campaign progresses (or even ultimately be
removed once the campaign has finished).

I think an important part of this idea here is that this doesn’t enable anything
that authors can’t already do, it just presents the information in a way that
is easier for other tooling to take advantage of it as well as allow us to make
more informed decisions about how to show it and when to show it without requiring
authors to update the long_description of their projects. I think it will also
be a strong signal that it’s OK for projects to ask for help (whether of the man
power or monetary kind) and will also help lead more projects to be more sustainable
for the long term.

As far as man power goes, part of that problem is that adding *anything* to the
current PyPI code base is a massive headache because there are zero tests and the
code base itself is horribly factored and a pain in the ass to work with. However
what we’re doing now is rewriting PyPI using a modern framework with modern
practices (test coverage, CSS frameworks, etc). When this gets completed adding
new features will be easier, especially for people who don’t regularly work on
PyPI itself.

Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150413/ac25157a/attachment-0001.sig>

More information about the Distutils-SIG mailing list