There are lots of options for this, and one thing worth keeping in mind is compatibility with the "monolithic system package" model, where the entire preconfigured virtual environment gets archived, and then dropped into place on the target system. In such cases, filesystem level mtimes may change *without* the entry point cache actually being out of date.

In that context, it's worth keeping in mind what the actual goals of the cache will be:

1. The entry point cache should ideally reflect the state of installed components in a given execution environment at the time of access. If this is not true, installing a component may require explicit cache invalidation/rebuilding to get things back to a consistent state (similar to the way a call to importlib.invalidate_caches() is needed to reliably see filesystem changes)

2. Checking for available entry points in a given group should be consistently cheap (ideally O(1)), rather than scaling with the number of packages installed or the number of sys.path entries

Given those goals, there are a number of different points in time where the cache can be generated, each with different trade-offs between how reliably fresh the cache is, and how frequently you have to rebuild the cache.

Option 1: in-memory cache

* Pro: consistent with the way importlib caches work

* Con: every process incurs at least 1 linear DB read

* Con: zero pay-off if you only query one entry point group

* Con: requires explicit invalidation to pick up filesystem changes (but can hook into importlib.invalidate_caches())

Option 2: temporary (or persistent) per-user-session cache

* Pro: only the first query per path entry per user session incurs a linear DB read

* Pro: given persistent cache dirs (e.g. XDG_CACHE_HOME, ~/.cache) even that overhead can be avoided

* Pro: sys.path directory mtimes are sufficient for cache invalidation (subject to filesystem timestamp granularity)

* Pro: zero elevated privileges needed (cache would be stored in a per-user directory tree)

* Con: if a non-persistent storage location is used, zero benefit over an in-memory cache for throwaway environments (e.g. container startup)

* Con: cost of the cache freshness check will still scale linearly with the number of sys.path entries

* Con: filesystem access control requires either explicit cache refresh or implicit metadata caching support in installers

Given those trade-offs, I think it would probably make the most sense to start out by exploring a combination of options 1 & 2, and then only explore option 3 based on demonstrated performance problems with a per-user-session caching model. My rationale for that is that even in an image based "immutable infrastructure" deployment model, it's often entirely feasible to preseed runtime caches as part of the build process, and in cases where that *isn't* possible, you're likely also going to have trouble generating per-path-entry caches.

Cheers,

Nick.