[Distutils] Entry points: specifying and caching

[Nick Coghlan]

On 26 October 2017 at 18:33, Thomas Kluyver <thomas at kluyver.me.uk> wrote:

> Nathaniel raises the point that it may be easier to convince other package
> managers to regenerate an entry points cache than to call arbitrary Python
> hooks on install.
>

At least for RPM, we have file triggers now, whereby system packages can
register a hook to say "Any time another package touches a file under <path
of interest> I want to know about it".

That means the exact semantics of any RPM integration would likely end up
just living in a file trigger, so it wouldn't matter to much whether that
trigger was "refresh these predefined caches" or "run any installed hooks
based on the defined Python level metadata".

However, I expect it would be much easier to define a "optionally export
data for caching in a more efficient key value store" API than it would be
to define an API for arbitrary pre-/post- [un]install hooks. In particular,
a caching API is much easier to *repair*, since the "source of truth"
remains the installation DB itself - the cache is just to speed up runtime
lookups.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20171026/f4c96bbc/attachment.html>