zlacker

> AnkiWeb

Worth noting you don't need to use it. Anki comes with a syncserver implementation for a while now, and there are docker images too. It's worth it for the transfer speeds alone IMO.

Anki is under AGPL too, which has an anti-DRM clause, so many type of enshittification of anki or their addons (e.g. to prevent sharing of their decks) would be unenforceable too.

As such I see no obvious things that would be susceptible to enshittification here.

>>digiow+(OP)
Aha [0], that is neat.

[0]: https://docs.ankiweb.net/sync-server.html

>>pityJu+E1
I've tried several times before to install syncserver using those pip instructions, on multiple platforms, without success.

>>bangon+L5
Try docker: https://github.com/ankitects/anki/tree/main/docs/syncserver#...

>>bangon+L5
Just as a counterpoint, to avoid people getting the wrong idea about the complexity involved - I use it and it took literally minutes. The most confusing part was that the sync settings in Ankidroid referred to Ankiweb.

>>dhoe+S21
Hey, could you put in an issue, especially regarding the pain points, but also including what 'seems unusual': https://github.com/ankidroid/Anki-Android

It's mostly due to time/resource/technical constraints [some of our strings come from a shared backend], but we can do better here, especially if there's now a lot more community interest in the feature.

Pull requests welcome! Do feel free to get in touch on the issue/Discord.

>>david_+4l1
Was about to do that, but it turned out it's already fixed in the current version - so literally the only minor issue I hit on my way to a custom sync server is resolved already :)

>>bangon+L5
The pip instructions are bad. Typical Python things: Non-reproducible, not involving a proper lock file. Cargo instructions seem not much better, since they are only referring to a tag in the git repo. The installation from "package build" leak user and password in shell history.

Overall this doesn't inspire much confidence in how solid and tested the procedure is.

>>zelphi+Tt1
The page is on GitHub:

https://github.com/ankitects/anki-manual/blob/main/src/sync-...

Full disclaimer - it's a feature which AnkiDroid supports, but isn't one which I use.

>>david_+CS1
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.

>>zelphi+c32
In fairness, Python as an ecosystem doesn't make it clear, either. I used to write a ton of Python back in the v2 days. I came back to Python to write a web crawler in summer 2025 and couldn't believe how it was still a bunch of arcane commands to create a virtual environment and install dependencies and capture the dependencies. Yes, an IDE like Pycharm handles this (thank goodness), but jiminy crickets, why doesn't "pip" refuse to even work until you've done "pip init" which generates a requirements.txt and then every pip install should check for a requirements.txt in the PWD. If it doesn't exist, refuse to install the dep. If the file does exist, append the version of the dep to that file.

It's 2026. Even JavaScript can do this.

pip is the de facto manager for the entire language. It should be better. With Node Package Manager for JS, the installation default is at the project level. You have to do a command line override to install globally.

PIP is the opposite. In fact, the only way to install at the project level is to create a virtual environment and trick PIP into thinking it's installing at the global level!

What language operates like this in 2026? Maven installs at the project level. Unison at the project level. Haskell at the project level. JS/TS at the project level.