Use pycrdt instead of y-py

[davidbrochart]

pycrdt is a new library providing Python bindings for Yrs. It speaks the "Y" protocol just like y-py, but has a different API.

[davidbrochart]

I was about to ask if the two libraries could be use transparently. But I'm seeing that it is definitely not possible.

It may be possible to create a wrapper around Ypy so that it has the same API as pycrdt, but at the same time pycrdt could evolve in a different direction in the future, so I'm not sure I should invest time in Ypy if in the end it's not possible for them to converge on the same API.

[echarles]

Linking here the discussion on https://github.com/jupyter-server/team-compass/issues/55, I guess we first need to have an understanding and agreement on y-py/pycrdt before merging this PR.

[ericsnekbytes]

Are there any tangible user-benefits (for end users) for switching to pycrdt? It should be front of mind that there's a cost to switching libraries, and not just the initial development cycles.

• How will build processes be affected by switching, unless there are zero impacts there?
• What additional rust dependencies/binaries need to be added?
• What any maintenance be expected in rust?
• What documentation needs to be written for maintainers and contributors for the switch to pycrdt?

Adding extra languages, binaries, tools and workflows can be a burden on maintainers and increase complexity and difficulty for new contributors. We should have a COMPLETE understanding of the impacts before moving forward. The cost of increased complexity, added dependencies and workflows should not be accepted unless end users are going to see substantial benefits...

[davidbrochart]

I'm obviously doing this for the good of the project. Ypy is close to being unmaintained, part of the reason being its complexity. With pycrdt I want to make my life easier in order to improve collaborative editing in Jupyter.

[davidbrochart]

I'll release v2.0.0.