Eager discovery, lazy loading of entry_points?

Feature

Expose general entry_point information in pyodide-lock.

Motivation

A number of stacks (matplotlib, pytest, etc.) rely on entry_points for extensible functionality, a relatively unique feature to Python.

These fall down with dependencies primarily intended to be fulfilled with loadPackagesFromImports, as it is expected the metadata about these will already be in site-packages.

The pyodide-build format doesn't borrow the entry_points (secretly, just console_scripts) feature from its syntactic ancestor conda-build, but that certainly shows how some things could work. Indeed, having console_scripts could be quite useful for emulating certain well-behaved CLI-like interactions.

Pitch

It would be very interesting if...

• pyodide-build supported declaring #/build/entry_points/{:ep-group}/
• pyodide-lock.json (or whatever flavor of pylock.toml + metadata ends up being used) contained this per-package information (or could be added after the fact with uv_pip_compile)
• metadata gets injected into calls to importlib.metadata.entry_points(group=...) without loading the whole package
• when an entry point is fully load()ed, trigger an install
  • ... somehow working around the async issues

Alternatives

• do nothing, relying on explicit micropip.install or equivalent

Additional context

An example which has caused some heartburn is the ipympl backend for matplotlib. The metadata might look like:

{
 #...
  "packages": {
    #...
    "ipympl": {
      #...
      "entry_points": {
        "matplotlib.backend": {
          "ipympl": "ipympl.backend_nbagg",
          "widget": "ipympl.backend_nbagg"
        }
      }
    }
  }
}

Calling %maptlotlib widget would see this, map it to ipympl, import it, and then use it without any further interaction.