Excerpts from Nathaniel Smith's message of 2017-10-20 13:41:03 -0700:
On Oct 19, 2017 11:10, "Donald Stufft" <donald@stufft.io> wrote:
EXCEPT, for the fact that with the desire to cache things, it would be beneficial to “hook” into the lifecycle of a package install. However I know that there are other plugin systems out there that would like to also be able to do that (Twisted Plugins come to mind) and that I think outside of plugin systems, such a mechanism is likely to be useful in general for other cases.
So heres a different idea that is a bit more ambitious but that I think is a better overall idea. Let entrypoints be a setuptools thing, and lets define some key lifecycle hooks during the installation of a package and some mechanism in the metadata to let other tools subscribe to those hooks. Then a caching layer could be written for setuptools entrypoints to make that faster without requiring standardization, but also a whole new, better plugin system could to, Twisted plugins could benefit, etc [1].
Having post-install and pre-uninstall hooks should be sufficient for updating a cache, assuming the hook could be given enough information about the thing being manipulated to probe for whatever data it needs.
In this hypothetical system, how do installers like pip find the list of hooks to call? By looking up an entrypoint? (Sorry if this was discussed downthread; I didn't see it but I admit I only skimmed.)
That's how I would expect it to work. Using setuptools most likely? That would mean that other plugin systems would have to provide one setuptools plugin to hook into the installer to build a lookup cache, but the actual plugins wouldn't have to use setuptools for anything. Doug