Comment by david_allison

I see. I am not claiming, that it is your job to fix that.

On that page though, the same issues are present. The pip install does not make use of any lock file.

    pip install anki

Isn't a command we should be seeing in 2026. Unless it is a one-off experiment setup. There should be proper lock files, not just version numbers, especially in the Python and JS ecosystems this has become less and less acceptable.

    SYNC_USER1=user:pass ~/syncserver/bin/python -m anki.syncserver

Leaks username and password to shell command history. Again, can be fine for a one-off quick hack, but is not a great practice, since the shell command history is not the most secure place to store ones credentials in. This could be easily mitigated by adding leading " " (space), at least in environments I am familiar with, but better would probably be putting the credentials in a config file, so that they never hit the shell command history.

The repo already has a lock file for uv. It would be better to make use of that lock file, when using Python to install. And in fact, when one downloads a release of Anki for desktop and runs it the first time, it does make use of uv, creating a venv, and (unconfirmed) hopefully makes use of the uv lock file.

I see these kinds of issues very frequently in Python projects. As someone, who has previously worked on providing docker images for data science workflows, enabling reproducible research, I am quite sensitive to this. But also I hear from friends, that they are traumatized by Python projects installing things in system python and other shenanigans. In general there seem to be tons of people doing Python projects, who don't have a clear idea of how to make things safe and reproducible, which is giving Python projects in general a bad reputation. All while good solutions to these problems exist and existed for years.