Can't install from sources

[jeandet]

In order to test #128, I installed locally pycrdt-websocket using pip install --upgrade --force git+https://github.com/y-crdt/pycrdt-websocket within my venv but I noticed 2 things:

• it install into pycrdt/websocket and I see nothing that would create a pycrdt_websocket package, I must have missed something.
• following the first issue, pycrdt is installed into venv/lib64/python3.13/site-packages/pycrdt while pycrdt-websocket is installed into venv/lib/python3.13/site-packages/pycrdt/websocket which makes it unreachable

I also tried to build a wheel locally cloning the repo with python -m build . but installing the wheel doesn't change anything (as I would expect).

Is there anything I missed?

[davidbrochart]

One thing that recently changed is that we now use package namespaces, so pycrdt-websocket is installed "inside" pycrdt and can be imported with:

import pycrdt.websocket

I'm not sure about the lib64 thing. I use micromamba to create environments and pycrdt is installed in my environment's lib/python3.13/site-packages/pycrdt.
Does that help?

[jeandet]

Ok, that makes sense for pycrdt.websocket rename.

For the install folder, that's an issue, I'm trying to find a solution.

[darabos]

One thing that recently changed is that we now use package namespaces, so pycrdt-websocket is installed "inside" pycrdt and can be imported with:

import pycrdt.websocket

I think this should be included in the release notes (https://github.com/y-crdt/pycrdt-websocket/releases/tag/0.16.0). The package name changing for sure impacts all users. After changing the package names and adding "type": "websocket" to the ASGI server scope, everything works for us! Thanks for the release! ❤

(By the way, our application that uses PyCRDT is open-source now: https://github.com/lynxkite/lynxkite-2000)

[davidbrochart]

Thanks @darabos, I updated the release notes.

(By the way, our application that uses PyCRDT is open-source now: https://github.com/lynxkite/lynxkite-2000)

Very nice!

[bnavigator]

As Linux package maintainer, I also want to stress out that having pycrdt in platlib (/usr/lib64/python3.13/site-packages/pycrdt) while having pycrdt.websocket and pycrdt.store in purelib (/usr/lib/python3.13/site-packages/pycrdt/websocket/) creates import errors:

[    4s] + cd /home/abuild/rpmbuild/BUILD/python-pycrdt-websocket-test-0.16.0-build
[    4s] + cd pycrdt_websocket-0.16.0
[    4s] + ls /usr/lib64/python3.13/site-packages/pycrdt
[    4s] __init__.py
[    4s] __pycache__
[    4s] _array.py
[    4s] _awareness.py
[    4s] _base.py
[    4s] _doc.py
[    4s] _map.py
[    4s] _provider.py
[    4s] _pycrdt.cpython-313-x86_64-linux-gnu.so
[    4s] _pycrdt.pyi
[    4s] _sync.py
[    4s] _text.py
[    4s] _transaction.py
[    4s] _undo.py
[    4s] _update.py
[    4s] _version.py
[    4s] _xml.py
[    4s] py.typed
[    4s] + ls /usr/lib/python3.13/site-packages/pycrdt
[    4s] store
[    4s] websocket
[    4s] + ls /usr/lib/python3.13/site-packages/pycrdt/websocket
[    4s] __init__.py
[    4s] __pycache__
[    4s] asgi_server.py
[    4s] awareness.py
[    4s] django_channels_consumer.py
[    4s] py.typed
[    4s] websocket.py
[    4s] websocket_server.py
[    4s] yroom.py
[    4s] yutils.py
[    4s] + PYTHONUNBUFFERED=1
[    4s] + python3 -c 'import sys; print(sys.path); import pycrdt; import pycrdt.websocket'
[    4s] ['', '/usr/lib64/python313.zip', '/usr/lib64/python3.13', '/usr/lib64/python3.13/lib-dynload', '/usr/lib64/python3.13/site-packages', '/usr/lib64/python3.13/_import_failed', '/usr/lib/python3.13/site-packages']
[    4s] Traceback (most recent call last):
[    4s]   File "<string>", line 1, in <module>
[    4s]     import sys; print(sys.path); import pycrdt; import pycrdt.websocket
[    4s]                                                 ^^^^^^^^^^^^^^^^^^^^^^^
[    4s] ModuleNotFoundError: No module named 'pycrdt.websocket'

This is masked in virtual environments because they have purelib and platlib point to the same place.

[davidbrochart]

Is it fixable with symbolic links?

[bnavigator]

Yes it's a viable (but IMHO ugly) workaround.