Add pyodide-lock.json customization with optional pyodide-lock and uv dependencies

[bollwyvl]

References

• for Provide pyodide-lock customization #250
• strawman demo over on Demo pyodide-lock PR 269 jupyterlite#1893
  • demo on ReadTheDocs

Changes

• pyproject.toml
  • add [lock] extra
• addons/piplite.py
  • move some reusable functions to a utils.py
• addons/pyodide.py
  • add lock_* traits
  • gate pyodide-lock behind PyodideAddon.lock_enabled
  • add tasks for configuring lock
• tests/test_lock.py
• .github/workflows
  • only test pyodide-lock and uv on 3.14
  • move coverage threshold here
• packages
  • normalize some package names in places (e.g. pyodide_kernel -> pyodide-kernel)
  • add proper dependencies on IPython, comm to pyodide-kernel/pyproject.toml
• examples
  • add specs for the latest IPython to demonstrate replacing packages added to pyodide for convenience (not ABI compatibility)
  • demonstrate the "full CDN" approach
  • remove %pip from example notebook
• docs
  • minimal update to README with compatibility information and CLI output

User-facing changes

• site authors will be able to:
  • more easily add custom wheels (and their dependencies) with --pyodide-wheels
  • reduce more sources of future flake with e.g. SOURCE_DATE_EPOCH now also being reflected in the runtime package set
• site visitors should see better performance from fewer requests
• the %pip syntax will be required in fewer scenarios, but is still available for exploring

Backwards-incompatible changes

• n/a

[github-actions]

👈 Try it on ReadTheDocs

[jtpio]

Nice, thanks!

Left a couple of comments after a first pass.

[bollwyvl]

Rekicked the RTD demo, merged up to 0.7.x.

[jtpio]

Looks good overall!

Since this targets the 0.7.x branch, just checking that are we not expecting anything to break or surprise users if this ends up in a patch release?

[bollwyvl]

not expecting anything to break or surprise users if this ends up in a patch release?

Yep, that's the motivation behind the lock_enabled feature flag, and running the 3.10 tests without uv and pyodide-lock around. Provided this lands and we get some real-world feedback, we could evaluate whether 0.8 should:

• add the [lock] stuff to requirements
• stop using piplite for pyodide-kernel, etc.

After some CI insight, I'll add another test excursion that checks with [lock] against 3.10.

[bollwyvl]

If we're really concerned, I can go back to a PyodideLockAddon in a new lock.py. This would reduce changes to pyodide.py, but would introduce some order-of-operations issues where PyodideLockAddon would need to know a fair amount about the things PyodideAddon is doing, and more boilerplate, and another key in the config file.

[jtpio]

Maybe it could be worth targeting main first, test in a pre-release, and then backport to 0.7.x if everything looks good?