Pip: PROPOSAL: A new subcommand, 'pip thank'

[bskinn]

Rationale

Recent events and discussions have highlighted the toxicity that can sometimes occur in FOSS communities, including Python's. Quoting @brettcannon's 2018 PyCon keynote:

Everyone needs to act like everything is being done as a kindness for them.

In furtherance of the goal of facilitating community members' expressing appreciation for the kindness done by developers and maintainers of Python packages, this issue proposes a new pip subcommand, "pip thank", to facilitate and encourage users to express thanks to project devs &c.

pip is proposed as the locus of this effort as it is a highly visible, central tool for many (most?) users of Python packages. Further, suitable metadata infrastructure appears already to be in place within setuptools/PyPI/Warehouse for this new subcommand to draw on, so implementation is anticipated to be relatively uncomplicated.

Proposed New Functionality

The proposed functionality would be embodied in a new pip subcommand, thank. As initially envisioned, it would take one or more arguments, to be interpreted as the names of PyPI packages, e.g.:

$ pip thank requests numpy

On this invocation, pip would retrieve the metadata md for each package and search/operate on it in a defined way:

1. If the project_urls key in md is defined:
   a. Look for a key called thank; if it exists, print('Thank {0}: {1}'.format(project_name, md['project_urls']['thank']))
   b. Look for a key called donate; if it exists, print('Donate to {0}: {1}'.format(project_name, md['project_urls']['donate']))

2. If project_urls is not defined, or if it is defined but neither the thank nor donate keys is present:
   a. If md['url'] is defined, print('Support {0} at: {1}'.format(project_name, md['url']
   b. Otherwise, print("Unfortunately, {} doesn't provide 'pip thank' information. :-/".format(project_name)

   thank could point to, say, a Twitter feed, a comment form on a website, or an email address/mailing list. donate could point to a PayPal donation box, a donation web form, etc.; or, it could be omitted for projects not seeking financial support.

In addition, the tail of the output from pip install invocations (and possibly others?) would be expanded to include (color-formatted?) text to the effect of:

Like these projects? Run 'pip thank {project}' for info on how to support them.

Implementation Hurdles

None anticipated.

As best as I can tell, the existence of the project_urls metadata field provides all the machinery needed for project authors/maintainers to specify where users can go to say "Thanks," or to provide financial support.

Using md['url'] as a fallback would result in most projects returning some destination upon a pip thank invocation; the pip thank output would transition smoothly to the more-specific information provided by project authors/maintainers as they add it to their metadata.

[ewdurbin]

A couple of thoughts/questions:

• What would be found at the thank url? Just a place to leave a note or some other form of appreciation? Edit: just read in Implementation Hurdles :)
• I think that Thank and Donate would be better keys, as we currently have a sort of de-facto standard of capitalization for URL labels, they're not specified beyond being under 32 chars. I suppose pip thanks could be case-insensitive anyway.
• This is a really clever and straight-forward opt-in method, I like it a lot.

[bskinn]

Hmm... @ewdurbin, the PEP 345 link says that project_url is a string; but, project_urls in the setuptoolsdocs says it's a mapping.

Which would this need to conform to?

[phildini]

This is a rad idea, and a large portion of this functionality is captured it https://github.com/phildini/thanks.

Always happy to take suggestions or directions for how to make it better.

As part of thanks, I added a Funding url to the sample python package, adding a Thanks url has been on my to-do for a while. Happy for someone else to take that on and add the functionality to thanks!

[ewdurbin]

Hmm... @ewdurbin, the PEP 345 link says that project_url is a string; but, project_urls in the setuptoolsdocs says it's a mapping.

Which would this need to conform to?

It's specified to setuptools as a dictionary, but is submitted to PyPI as per spec :)

https://github.com/pypa/setuptools/blob/566f3aadfa112b8d6b9a1ecf5178552f6e0f8c6c/setuptools/dist.py#L90-L91

[illume]

Love it. pip thank > you.

• For each dependency installed, show donation links chosen by project.
• List donation URLs on pypi too (currently there is just a donation link to pypi, not to everyone who provides the actual content).
• printing the URLS on install would be appreciated, rather than having a separate command no one will notice.

[pradyunsg]

I like this idea. I think the "say thanks to these projects using 'pip thanks'" on install is a great way to add visibility to the command. :)

[bskinn]

@illume:

• _printing the URLS on install would be appreciated, rather than having a separate command no one will notice._

I thought about proposing it this way, but what about the case of a pip install -r requirements.txt that installs a couple dozen packages? The pip thank content would then be massive, and thus highly intrusive. I would prefer to accept the decreased visibility of the separate pip thank subcommand.

[illume]

A line for each dependency is useful and respectful
of all the hard work that goes into this stuff.

Hiding the project URLs behind a command no one will even know is there seems wrong.

[bskinn]

[NOTE TO SELF] If I read the code for the install command correctly, a good place to put the printing of this message:

Like these projects? Run 'pip thank {project}' for info on how to support them.

would be right after this line, inside the if installed: suite.

Probably this would be a call to a new helper function housed somewhere in pip/src/pip/_internal/utils .

Colorization could reuse this logging function, given a suitable check for colorama.

[illume]

Oh good. So, installing requests for example will show all the libraries requests is built on, and then shows "Like these projects? Run 'pip thank {project}' for info on how to support them." at the end.

I think it's helpful to see how the whole thing would look together...

$ pip install requests
Collecting requests
  Using cached https://files.pythonhosted.org/packages/f1/ca/10332a30cb25b627192b4ea272c351bce3ca1091e541245cccbace6051d8/requests-2.20.0-py2.py3-none-any.whl
Collecting certifi>=2017.4.17 (from requests)
  Using cached https://files.pythonhosted.org/packages/56/9d/1d02dd80bc4cd955f98980f28c5ee2200e1209292d5f9e9cc8d030d18655/certifi-2018.10.15-py2.py3-none-any.whl
Collecting idna<2.8,>=2.5 (from requests)
  Using cached https://files.pythonhosted.org/packages/4b/2a/0276479a4b3caeb8a8c1af2f8e4355746a97fab05a372e4a2c6a6b876165/idna-2.7-py2.py3-none-any.whl
Collecting urllib3<1.25,>=1.21.1 (from requests)
  Using cached https://files.pythonhosted.org/packages/8c/4b/5cbc4cb46095f369117dcb751821e1bef9dd86a07c968d8757e9204c324c/urllib3-1.24-py2.py3-none-any.whl
Collecting chardet<3.1.0,>=3.0.2 (from requests)
  Using cached https://files.pythonhosted.org/packages/bc/a9/01ffebfb562e4274b6487b4bb1ddec7ca55ec7510b22e4c51f14098443b8/chardet-3.0.4-py2.py3-none-any.whl
Installing collected packages: certifi, idna, urllib3, chardet, requests
Successfully installed certifi-2018.10.15 chardet-3.0.4 idna-2.7 requests-2.20.0 urllib3-1.24
Like these projects? Run 'pip thank {project}' for info on how to support them.

A little note: how about "pip thank {package}"? Because, it lists the "packages: certifi, idna, urllib3, chardet, requests" there. It says nothing about projects, so changing it to "{package}" will perhaps be more clear.

---

Here is what the project_urls will look like according to the proposal, and the example from the setuptools project_urls documentation.

    project_urls={
        "Bug Tracker": "https://bugs.example.com/HelloWorld/",
        "Documentation": "https://docs.example.com/HelloWorld/",
        "Source Code": "https://code.example.com/HelloWorld/",
        "Thank": "https://code.example.com/thank/",
        "Donate": "https://code.example.com/donate/",
    }

A small note: "thank", and "donate" should accept capitalized versions as well.

---

$ pip thank requests
requests
    Thank requests: https://code.example.com/thank/
    Donate requests: https://code.example.com/donate/
    Contributors(525): https://github.com/project/repo/graphs/contributors
certifi
    Thank certifi: https://certifi.example.com/thank/
    Donate certifi: https://certifi.example.com/donate/
    Contributors(111): https://github.com/project/repo/graphs/contributors
idna
    Thank idna: https://idna.example.com/thank/idna
    Donate idna: https://idna.example.com/donate/idna
    Contributors(111): https://github.com/project/repo/graphs/contributors
urllib3
    Thank urllib3: https://certifi.example.com/thank/urllib3
    Donate urllib3: https://certifi.example.com/donate/urllib3
    Contributors(128): https://github.com/project/repo/graphs/contributors
chardet
    Thank chardet: https://certifi.example.com/thank/chardet
    Donate chardet: https://certifi.example.com/donate/chardet
    Contributors(111): https://github.com/project/repo/graphs/contributors

---

ps. Another source of credit is the "contributors" link on github.
For example: you can see the 525 contributors listed against the requests package here: https://github.com/requests/requests/graphs/contributors
Perhaps this would also be useful to print out somehow?

---

[ED: added a bigger example of what pip thank requests could look like]

[xanderyzwich]

I think that it could even be a nice thought that pip thanks requirements.txt > thanks.txt could be a great way to interconnect our projects to the ones that we depend on. This is especially true if perhaps a larger known project is making use of something more obscure or underfunded.

[bskinn]

@pradyunsg Response seems to be generally positive. I'm willing to take a crack at implementing. Shall I go ahead, and discussion can continue once I have an initial PR?

[pradyunsg]

Sounds good to me. We should probably hash out how the command would look and fetch data here (i.e. design) and then discuss the implementation in the PR.

/cc @pypa/pip-committers

[bskinn]

@pradyunsg Yeah, I have no idea about any local caching of the package listings/metadata/whatnot that could be exploited to minimize/eliminate bandwidth for pip thank calls -- those sorts of internal infrastructure aspects might argue against me spearheading an implementation.

[ghost]

similar to #994

[bskinn]

[TERMINOLOGY]

@illume:

A little note: how about "pip thank {package}"? Because, it lists the "packages: certifi, idna, urllib3, chardet, requests" there. It says nothing about projects, so changing it to "{package}" will perhaps be more clear.

On reflection, I completely agree with you here. I think, technically, the entities that are installed from PyPI are called 'projects', since a given pip install X could install any number of 'Python packages' (or none!).

But, absolutely: since pip install calls them packages, pip thank should too!

[bskinn]

[FEATURE]

@xanderyzwich:

I think that it could even be a nice thought that pip thanks requirements.txt > thanks.txt could be a great way to interconnect our projects to the ones that we depend on. This is especially true if perhaps a larger known project is making use of something more obscure or underfunded.

I agree, I think implementing pip thanks -r requirements.txt would make sense.

[ghost]

Is this not similar to #994 ?

[bskinn]

@snow8gaia: No, the aim and scope of this proposal are significantly different from #994. That proposal was to integrate pip directly with specific donation/payments machinery; this one would just add printing to console of specific project metadata.

A key goal here is to balance putting support/thanks/donation information in front of users while minimizing the implementation and maintenance burden for the pip/PyPA team.

[brettcannon]

I was thinking about this and probably thanking pip, pip's dependencies, and Python should probably automatically be thanked at the end of the output. 😁

[bskinn]

Agreed, @brettcannon, I'd also been thinking along these lines... though, I hadn't actually thought about pip itself! :sob:

I could see wanting to make special provision for:

• pip
• pip's _vendor dependencies (especially ones outside the PyPA umbrella; colorama, etc.)
• PyPA
• Python (code side---core devs, mainly?)
• PSF (administrative/structural side)

These would have the potential to be awfully bulky, if they were included in every pip thank invocation. I'd been noodling with the idea of a special python argument to pip thank, which would, say, print the info for Python/PSF/PyPA; similarly, the nicely circular pip thank pip could print the info for pip and its dependencies. An info message like the following could then be added somewhere:

'pip thank python' shows support information for Python and its governing organizations
'pip thank pip' shows support information for pip and its dependencies

Some of this content would probably have to be specially provided for, either via 'special' PyPI package(s), curated by PyPA; or via magic objects in the pip source, curated by the pip maintainers. Neither approach should be particularly burdensome..?

[brettcannon]

You could say at the end "And please don't forget to thank pip, its dependencies, your Python implementation, and the Python Software Foundation." and just keep it simple. Otherwise even with Python it gets murky since what do you do when running under PyPy?

[bskinn]

@brettcannon I'm all for simple! pip thank pip is simple enough, at least, and delightfully recursive in the same vein as pip install -U pip.

For the PSF and Python implementations, though, it seems a bad idea either (1) to omit explicit links to thank/donate targets (since a big piece of the idea is making these targets super-easy to find), or (2) to embed the thank/donate targets into pip, thus (a) requiring a version bump to change the targets and (b) necessarily slowing the pace of target changes to match the pip release schedule. I'd much prefer either (i) implementing some special package argument(s) into pip thank (e.g., pip thank --implementation jython or somesuch), or (ii) creating ~metadata-only PyPI packages for the implementations (leading to, e.g., pip thank py-impl-jython). That way, the targets could be curated at-need, by the relevant stakeholders.

The trick with pip's dependencies, AFAICT, is that they're all(?) vendored: none of them even show up in setup.py as requires=[...]. Something would have to be introduced to curate/scrape a list for display to users, seems to me. Might suffice to print a list of the subdirectories under https://github.com/pypa/pip/tree/master/src/pip/_vendor? pkg_resources (at least) isn't a valid PyPI package, though....

[pradyunsg]

We have a pip/_vendor/vendor.txt, where all the vendored dependencies are linked.

I'm not sure whether it makes it into the wheel/installed files though. Plus, there's the case where distros unvendor pip itself, in which case, we won't have that information.

[bskinn]

@pradyunsg Looks like an updated list of the vendored dependencies has to be maintained in src/pip/_vendor/__init__.py, to allow debundling of the dependencies by others. If that linked series of vendored(...) invocations were refactored to a dependencies list and for d in dependencies: vendored(d) loop, it seems like it would be straightforward to import that dependencies list and parse it for pip thank purposes... say, set(d.partition(".")[0] for d in dependencies).

[illume]

Vendored and C/C++/other dependencies aren't really covered by this proposal or the python dependency system generally. Except that people can give credit on their LICENSE, README files and also on their web pages. IMHO since C/C++/other dependencies are not handled by the packaging system currently, it makes sense not to block this proposal because of that.

TLDR; In any case, this proposal is good because it can be quite useful with what we have now.

ps. I hope eventually pip should become good enough such that pip can uses it's own dependency system for itself? I feel perhaps packages(like pip) that vendor things outside the correct way of dealing with dependencies should just have to deal with things themselves. There's no specification for vendored packages. Similarly with CPython. I feel it really should be on pypi and just be dealt with like every other package/project on there. Eventually the packaging system should be good enough to distribute apps like CPython, and special casing it should not be necessary. I have similar hopes for C/C++ package management, that one of the systems there will mature enough such that python can integrate with them (eg. https://conan.io/). But like there is no pep/spec for specifying Debian/Ubuntu dependencies, this thank command shouldn't have to be blocked by this.

[pradyunsg]

Looks like an updated list of the vendored dependencies has to be maintained

Uh, no. My understanding is that list isn't maintained by pip's developers directly. That whole file, is basically there to reduce the size of patches that distros apply when debundling pip itself (and they're mostly helping keep that list up to date) -- I'm not sure if it's explicitly written anywhere that this is the case though.

TBH, I'd rather have us figure out how pip thank pip can be made to work separately; since pip is really a special case when doing this.

[bskinn]

@pradyunsg pip itself is an easy case, b/c the relevant metadata can be curated directly in its PyPI project.

Uh, no. My understanding is that list isn't maintained by pip's developers directly.

Bah! Ok, well then... for the dependencies, how about a tweak on @brettcannon's suggested message? Something like:

And please don't forget to thank pip, its dependencies (see https://github.com/pypa/pip/tree/master/src/pip/_vendor), your Python implementation, and the Python Software Foundation.

[illume]

I feel it really helps a lot to see how it would look when calling the commands on an example package...

Put it at the top of pip thank requests ?

$ pip install requests
Collecting requests
  Using cached https://files.pythonhosted.org/packages/f1/ca/10332a30cb25b627192b4ea272c351bce3ca1091e541245cccbace6051d8/requests-2.20.0-py2.py3-none-any.whl
Collecting certifi>=2017.4.17 (from requests)
  Using cached https://files.pythonhosted.org/packages/56/9d/1d02dd80bc4cd955f98980f28c5ee2200e1209292d5f9e9cc8d030d18655/certifi-2018.10.15-py2.py3-none-any.whl
Collecting idna<2.8,>=2.5 (from requests)
  Using cached https://files.pythonhosted.org/packages/4b/2a/0276479a4b3caeb8a8c1af2f8e4355746a97fab05a372e4a2c6a6b876165/idna-2.7-py2.py3-none-any.whl
Collecting urllib3<1.25,>=1.21.1 (from requests)
  Using cached https://files.pythonhosted.org/packages/8c/4b/5cbc4cb46095f369117dcb751821e1bef9dd86a07c968d8757e9204c324c/urllib3-1.24-py2.py3-none-any.whl
Collecting chardet<3.1.0,>=3.0.2 (from requests)
  Using cached https://files.pythonhosted.org/packages/bc/a9/01ffebfb562e4274b6487b4bb1ddec7ca55ec7510b22e4c51f14098443b8/chardet-3.0.4-py2.py3-none-any.whl
Installing collected packages: certifi, idna, urllib3, chardet, requests
Successfully installed certifi-2018.10.15 chardet-3.0.4 idna-2.7 requests-2.20.0 urllib3-1.24
Like these projects? Run 'pip thank {project}' for info on how to support them. For example:
pip thank requests

$ pip thank requests
---- snip this stuff below and put the message in here? ---
Please don't forget to thank pip, its dependencies 
(see https://github.com/pypa/pip/tree/master/src/pip/_vendor), your {platform.python_implementation()} 
and it's dependencies (gcc, glibc, sqlite, zlib, bsddb, openssl, cfuhash, libffi, expat, tcl-tk, readline, setuptools, ...), 
your python platform maintainer (Debian, Fedora, Homebrew, ...), 
Thanks to the people who ported Python to iOS,
thanks to the people who ported it to NetBSD on Power9 CPUs.
Thanks should go to the people who ported python to Android,
to Nokia phones, and those who ported it to run on my smart lightbulbs (without which I couldn't clap my hands to be able to see at night time!).
Thanks should go to those who tried to port it to run ontop of JavaScript, and ActionScript.
Thank IRC, and freenode. Thank the moinmoin, the mailman, and the email servers.
Of course bash should get thanks for letting us start python.
Please thank the bloke who moderates the python mailing list and answers all your hard questions
on stack overflow (making him do all the customer support for free is sort of mean of us...
please forgive us!!!).
and the Python Software Foundation for providing a tax efficient vehicle for corporations to donate their monies towards software they use for profit. But also for the excellent stickers they give out.
(apart from stickers they also give plenty of support to brilliant people all over the world).
Oh, and the EuroPython Society, the Python UK people, PyLadies Berlin, PyLadies...
the anonymous person who gave Guido a cup of tea that time when he was feeling sick
Please thank the internet. Thanks email. Thanks vim (ok... and emacs).
Even though this is pip, thanks easy_install, the cheese shops, and the setuptools people.
Please thank the Vaults of Parnassus people.
Who wrote all those windows COM bindings again? Wow. they deserve a standing ovation for dealing with that for us.
Did I already thank sed, grep, awk, autotools, Gnu Make, Gnu Linux, Gnu sandwich?
Fine, even Google and Microsoft get a special mention (despite both being fined multiple times for terrible actions). There are some really sweet people working there!! Also, thank youtube.
Thank that guy who lives in the mountains of Switzerland for doing really tricky stuff 
no one else in the world has been able to do (even with resources).
Thank gif and cats, for without which there would be no digital photography or internet.
Please give special thanks to the 90s, to Amsterdam, and to Dutch people.

**Thank British comedy from the 80s**, especially John Cleese who gave those
brilliant lectures about creativity (watch them now! you can thank me later).
https://docs.python.org/3/license.html#licenses-and-acknowledgements-for-incorporated-software
---- snip this stuff above and put the message in here? ---

requests
    Thank requests: https://code.example.com/thank/
    Donate requests: https://code.example.com/donate/
    Contributors(525): https://github.com/project/repo/graphs/contributors
certifi
    Thank certifi: https://certifi.example.com/thank/
    Donate certifi: https://certifi.example.com/donate/
    Contributors(111): https://github.com/project/repo/graphs/contributors
idna
    Thank idna: https://idna.example.com/thank/idna
    Donate idna: https://idna.example.com/donate/idna
    Contributors(111): https://github.com/project/repo/graphs/contributors
urllib3
    Thank urllib3: https://certifi.example.com/thank/urllib3
    Donate urllib3: https://certifi.example.com/donate/urllib3
    Contributors(128): https://github.com/project/repo/graphs/contributors
chardet
    Thank chardet: https://certifi.example.com/thank/chardet
    Donate chardet: https://certifi.example.com/donate/chardet
    Contributors(111): https://github.com/project/repo/graphs/contributors

Joking aside, probably the "please thank everyone else" line should be kept short and somehow all inclusive. (Also probably that text could be a starting point for the missing thankyou page on python.org)

[bskinn]

@illume, overdue thanks for creating draft command output!

Successfully installed certifi-2018.10.15 chardet-3.0.4 idna-2.7 requests-2.20.0 urllib3-1.24 Like these packages? Run 'pip thank {package}' for info on how to support them. For example: pip thank requests

This is pretty much what I had in mind, though I'd prefer to add a newline above the pip thank stuff, for readability.

Successfully installed certifi-2018.10.15 chardet-3.0.4 idna-2.7 requests-2.20.0 urllib3-1.24

Like these packages? Run 'pip thank {package}' for info on how to support them.
For example: pip thank requests

For a plain pip thank requests invocation, I'm picturing just printing the information for requests:

$ pip thank requests

Thanks for contributing to a positive environment in the Python community!

requests
    To say thanks: https://code.example.com/thank/
    To donate: https://code.example.com/donate/
    Contributors list: https://github.com/project/repo/graphs/contributors

As well, please don't forget to thank pip itself, pip's dependencies
(see https://github.com/pypa/pip/tree/master/src/pip/_vendor),
your Python implementation, and the Python Software Foundation.

If someone should want to print thank information for the full set of dependencies, I would envision implementing a --deps argument, which would perform a complete dependencies resolution for the provided package(s) and output everything it found.

[pradyunsg]

Eventually the packaging system should be good enough to distribute apps like CPython, and special casing it should not be necessary.

That sounds like a very broad requirement for a tool whose scope is being an installer for Python Packages. I don't think we're going to get to a point of pip install cpython being a reasonable way to install CPython. Let's not digress here though.

---

I'm ambivalent on printing dependencies by default in pip thank so I'm fine either way. I guess pip thank is restricted to only installed packages, is that correct?

[bskinn]

I'm ambivalent on printing dependencies by default in pip thank so I'm fine either way. I guess pip thank is restricted to only installed packages, is that correct?

I was thinking by default it would reach out to PyPI. The metadata would be drawn from https://pypi.org/pypi/{package}/json (props to @phildini for having figured this out already); IIUC the net traffic for calls to the PyPI JSON API should be minimal, compared to normal pip install load?

A --local option could be implemented, only searching locally-installed packages... say, for situations where someone doesn't have Internet access. Having no connectivity would kind of make it hard for them to do any thanking right then, though.

[illume]

It feels sort of weird to have more text in a more prominent place asking people to thank pip and python rather than the package they are asking info for. Strange feels also for hiding the dependencies by default. Anyway... I've said enough, I'm out.

[bskinn]

[REQUEST FOR INPUT]

@illume raises a good point for discussion: should pip thank print "thanks" info for package dependencies by default, or not? As noted, my first reflex was only to print "thanks" info for package dependencies if explicitly requested by --deps; but, it would certainly work to print --deps by default, and only suppress if --no-deps is passed.

To all: please register your preference by adding a reaction to this comment:

:+1: pip thank SHOULD print dependencies' information by default
:-1: pip thank should NOT print dependencies' information by default

Thanks!

[pradyunsg]

I was thinking by default it would reach out to PyPI.

Ah cool. Makes sense. I was specifically thinking about how to handle extras in this scenario -- ideally they should be thanked too if you're thanking dependencies.

[bskinn]

@illume:

It feels sort of weird to have more text in a more prominent place asking people to thank pip and python rather than the package they are asking info for.

I agree -- as I was typing out that example block I was thinking that it looked awfully bulky. Am definitely interested in ideas for other, more streamlined ways of handling the "thank pip/Python/PSF too!" reminder.

[xanderyzwich]

I'd say:
don't forget pip and dependencies seen by 'pip show pip'

[Ricyteach]

This idea is great and I like the direction it is going.

An additional suggestion (already talked with Brian about it offline but he encouraged me to post here):

Seems like it would be useful to provide _very minimal_ machinery for letting the maintainer know, _if they want to know_, that the thank command was invoked with their package as a target. To flesh that out just a little bit: I suggest for pip thank to fire off a minimal, predefined (i.e., maybe not even dynamically created) "thank you message"- or even just a ping- to some creator-defined URI. The creator can do with those pings what they will.

The rationale for this seems basic to me. As currently proposed, when invoking pip thank you are not actually "thanking" anyone yet. It's just pointing you to a place to do some thanking. But as a user, I would expect that command to- at minimum- at least send _some kind_ of thank you upon invocation. Without that, it would feel broken, or at least, less than fully useful.

I'm not a web guru so I don't have any specific suggestions on what the content of that message would _be_, exactly. But I do think, again, that it should be as minimal as can be. All that should happen is basically for the creator-provided URI to just be "pinged", perhaps with some kind of message (though I'm even open to the idea of no message content at all), without waiting for any kind of response, or anything like that. All that happens is the command line attempts to fire off a packet to the URI - additionally, failure would occur silently.

Of course there should also be the ability for an install to permanently turn these pings off, for security reasons. I'm sure there are plenty of reasons you would not want the machine you are on broadcasting its public IP out to dozens of random URIs. I also am assuming that if there is a message, it would be best for security for it to contain no information about the installing machine or anything like that.

EDIT: assuming this idea doesn't open up too many security concerns, I suggest "Thank Now" as the key for the target URI in project_urls:

project_urls={
    "Bug Tracker": "https://bugs.example.com/HelloWorld/",
    "Documentation": "https://docs.example.com/HelloWorld/",
    "Source Code": "https://code.example.com/HelloWorld/",
    "Thank": "https://code.example.com/thank/",
    "Thank Now": "https://code.example.com/thank-receive/",
    "Donate": "https://code.example.com/donate/",
}

-- Rick

[1313e]

This idea is great and I like the direction it is going.

An additional suggestion (already talked with Brian about it offline but he encouraged me to post here):

Seems like it would be useful to provide _very minimal_ machinery for letting the maintainer know, _if they want to know_, that the thank command was invoked with their package as a target. To flesh that out just a little bit: I suggest for pip thank to fire off a minimal, predefined (i.e., maybe not even dynamically created) "thank you message"- or even just a ping- to some creator-defined URI. The creator can do with those pings what they will.

The rationale for this seems basic to me. As currently proposed, when invoking pip thank you are not actually "thanking" anyone yet. It's just pointing you to a place to do some thanking. But as a user, I would expect that command to- at minimum- at least send _some kind_ of thank you upon invocation. Without that, it would feel broken, or at least, less than fully useful.

What about a very simple counter on the project webpage in the PyPI warehouse, that automatically counts the number of times pip thanks {package} was executed (and maybe limiting the number of times this can be done to 1 per Python installation or something)?
Then, that counter could be grabbed by other plugins, allowing it for example to be displayed on the GitHub repository using a badge.

[cs01]

This is a cool idea with great intentions. As an open source dev I always love hearing thanks. Just wanted to mention a couple things

• The commanding nature of "don't forget to say thanks" comes off a little patronizing. What if I already said thanks? What if I don't want to for whatever reason? I suggest something more neutral like "this project can be thanked by doing xyz".
• Like a warning that doesn't actually cause a fatal error, developers will start to instinctively filter these messages when reading output and eventually ignore them. Perhaps only printing them once every 10 installs or at random intervals would keep the message from being ignored.

[Ricyteach]

What about a very simple counter on the project webpage in the PyPI warehouse, that automatically counts the number of times pip thanks {package} was executed (and maybe limiting the number of times this can be done to 1 per Python installation or something)?
Then, that counter could be grabbed by other plugins, allowing it for example to be displayed on the GitHub repository using a badge.

This makes a lot of sense and is even simpler than my idea, requiring no additional effort on the part of the package creator. I like it. And if one wanted to, presumably one could "hook into" that PyPI thanks count in some way. Still very "opt-in" which is the spirit behind the entire thank command idea as proposed.

[bskinn]

@1313e (cc @Ricyteach) One significant downside to integrating this feature into PyPI: AFAICT it would require tandem development in both the codebase and database schemas of warehouse, as well as implementing the code in pip.

A generic ping URL should allow projects to use existing services like IFTTT to field the pings, and redirect them to whatever reporting/aggregation tooling they prefer. Plus, it would be easier to implement, and wouldn't introduce a new pip-warehouse interdependency.

[bskinn]

@cs01, I like the idea of randomizing whether the message shows, to avoid attention fatigue. Every n installs would require tracking install counts in some fashion, which sounds rather more complex.

See my comment above for a more complete current draft of the language I'd plan to implement. I believe the "don't forget pip and dependencies seen by 'pip show pip'" language was just a suggestion for how to streamline this chunk:

As well, please don't forget to thank pip itself, pip's dependencies
(see https://github.com/pypa/pip/tree/master/src/pip/_vendor),
your Python implementation, and the Python Software Foundation.

[1313e]

@1313e (cc @Ricyteach) One significant downside to integrating this feature into PyPI: AFAICT it would require tandem development in both the codebase and database schemas of warehouse, as well as implementing the code in pip.

A generic ping URL should allow projects to use existing services like IFTTT to field the pings, and redirect them to whatever reporting/aggregation tooling they prefer. Plus, it would be easier to implement, and wouldn't introduce a new pip-warehouse interdependency.

I understand that, but I get the feeling that having both in this case would work really well.
Have the counter in the warehouse and, if a Thank(s) project URL is present in the setup.py, ping that as well.
I get that it requires extra work on the PyPI side, but I am pretty sure that most developers will not think about putting a Thank ping URL in their project descriptions, either because it takes too much effort or they think it will not be used.
Only the big projects will expect a thanks from others, but they most likely already have some sort of system for this in place.

My point here is, that I really like the idea, but it should be accessible by all projects automatically, without requiring additional work.
It is a bit like getting a star on your GitHub repository; it indicates that someone finds your repository important enough that they want to give it a star (either to find it later or simply to express their gratitude), which may convince you to put more effort into it or something.
If it introduces an inter-dependency that might cause problems, then I guess it cannot be helped, but I would really like to see it happen.

[bskinn]

@cs01 (and others): What if the 'pip thank' message also showed in a random color, when it showed? (Say, picked from cyan/magenta/yellow/bright green/bright blue/bright purple/etc., avoiding the red of errors and the orange of warnings?)

[cs01]

The more I think about this, the more I think nothing should be displayed on install. Adding the thank command would be enough. Then the thousands (millions?) of devs in the community would be aware of it by viewing documentation or blogs, and use it at their discretion. Random colors, IMO, would be distracting and give a more amateurish feel to the tool.

[pradyunsg]

I suggest avoiding bikeshedding on how the message should be / look, until we have the command implemented. Addition of the message can only come after the command is implemented anyway.

[jefftriplett]

TIL that NPM added support for: npm fund <package name>. I just wanted to add that here in case seeing what they used is helpful nor should it dictate what the feature/command is called.

https://www.theregister.co.uk/2019/11/06/npm_fund/

[bskinn]

Just to poke my head back in--I haven't forgotten about this, and do still plan to put together a POC at some point.

Just, y'know. Life.