95dbf30fb9
All platforms: - rename scripts/ to tools/: Bazelisk expects to find its wrapper script (used by the Mac changes below) in tools/. Rather than have a separate scripts/ and tools/, it's simpler to just move everything into tools/. - wheel outputs and binary bundles now go into .bazel/out/dist. While not technically Bazel build products, doing it this way ensures they get cleaned up when 'bazel clean' is run, and it keeps them out of the source folder. - update to the latest Bazel Windows changes: - bazel.bat has been removed, and tools\setup-env.bat has been added. Other scripts like .\run.bat will automatically call it to set up the environment. - because Bazel is now on the path, you can 'bazel test ...' from any folder, instead of having to do \anki\bazel. - the bat files can handle being called from any working directory, so things like running "\anki\tools\python" from c:\ will work. - build installer as part of bundling process Mac changes: - `arch -arch x86_64 bazel ...` will now automatically use a different build root, so that it is cheap to switch back and forth between archs on a new Mac. - tools/run-qt* will now automatically use Rosetta - disable jemalloc in Mac x86 build for now, as it won't build under Rosetta (perhaps due to its build scripts using $host_cpu instead of $target_cpu) - create app bundle as part of bundling process Linux changes: - remove arm64 orjson workaround in Linux bundle, as without a readily-available, relatively distro-agonstic PyQt/Qt build we can use, the arm64 Linux bundle is of very limited usefulness. - update Docker files for release build - include fcitx5 in both the qt5 and qt6 bundles - create tarballs as part of the bundling process
119 lines
3.5 KiB
Markdown
119 lines
3.5 KiB
Markdown
# Building and running Anki in Docker
|
|
|
|
This is an example Dockerfile contributed by an Anki user, which shows how Anki
|
|
can be both built and run from within a container. It works by streaming the GUI
|
|
over an X11 socket.
|
|
|
|
Building and running Anki within a container has the advantage of fully isolating
|
|
the build products and runtime dependencies from the rest of your system, but it is
|
|
a somewhat niche approach, with some downsides such as an inability to display natively
|
|
on Wayland, and a lack of integration with desktop icons/filetypes. But even if you
|
|
do not use this Dockerfile as-is, you may find it useful as a reference.
|
|
|
|
Anki's Linux CI is also implemented with Docker, and the Dockerfiles for that may
|
|
also be useful for reference - they can be found in `.buildkite/linux/docker`.
|
|
|
|
# Build the Docker image
|
|
|
|
For best results, enable BuildKit (`export DOCKER_BUILDKIT=1`).
|
|
|
|
When in this current directory, one can build the Docker image like this:
|
|
|
|
```bash
|
|
docker build --tag anki --file Dockerfile ../../
|
|
```
|
|
|
|
When this is done, run `docker image ls` to see that the image has been created.
|
|
|
|
If one wants to build from the project's root directory, use this command:
|
|
|
|
```bash
|
|
docker build --tag anki --file docs/docker/Dockerfile .
|
|
```
|
|
|
|
# Run the Docker image
|
|
|
|
Anki starts a graphical user interface, and this requires some extra setup on the user's
|
|
end. These instructions were tested on Linux (Debian 11) and will have to be adapted for
|
|
other operating systems.
|
|
|
|
To allow the Docker container to pull up a graphical user interface, we need to run the
|
|
following:
|
|
|
|
```bash
|
|
xhost +local:root
|
|
```
|
|
|
|
Once done using Anki, undo this with
|
|
|
|
```bash
|
|
xhost -local:root
|
|
```
|
|
|
|
Then, we will construct our `docker run` command:
|
|
|
|
```bash
|
|
docker run --rm -it \
|
|
--name anki \
|
|
--volume $HOME/.local/share:$HOME/.local/share:rw \
|
|
--volume /etc/passwd:/etc/passwd:ro \
|
|
--user $(id -u):$(id -g) \
|
|
--volume /tmp/.X11-unix:/tmp/.X11-unix:rw \
|
|
--env DISPLAY=$DISPLAY \
|
|
anki
|
|
```
|
|
|
|
Here is a breakdown of some of the arguments:
|
|
|
|
- Mount the current user's `~/.local/share` directory onto the container. Anki saves things
|
|
into this directory, and if we don't mount it, we will lose any changes once the
|
|
container exits. We mount this as read-write (`rw`) because we want to make changes here.
|
|
|
|
```bash
|
|
--volume $HOME/.local/share:$HOME/.local/share:rw
|
|
```
|
|
|
|
- Mount `/etc/passwd` so we can enter the container as ourselves. We mount this as
|
|
read-only because we definitely do not want to modify this.
|
|
|
|
```bash
|
|
--volume /etc/passwd:/etc/passwd:ro
|
|
```
|
|
|
|
- Enter the container with our user ID and group ID, so we stay as ourselves.
|
|
|
|
```bash
|
|
--user $(id -u):$(id -g)
|
|
```
|
|
|
|
- Mount the X11 directory that allows us to open displays.
|
|
|
|
```bash
|
|
--volume /tmp/.X11-unix:/tmp/.X11-unix:rw
|
|
```
|
|
|
|
- Pass the `DISPLAY` variable to the container, so it knows where to display graphics.
|
|
|
|
```bash
|
|
--env DISPLAY=$DISPLAY
|
|
```
|
|
|
|
# Running Dockerized Anki easily from the command line
|
|
|
|
One can create a shell function that executes the `docker run` command. Then one can
|
|
simply run `anki` on the command line, and Anki will open in Docker. Make sure to change
|
|
the image name to whatever you used when building Anki.
|
|
|
|
```bash
|
|
anki() {
|
|
docker run --rm -it \
|
|
--name anki \
|
|
--volume $HOME/.local/share:$HOME/.local/share:rw \
|
|
--volume /etc/passwd:/etc/passwd:ro \
|
|
--user $(id -u):$(id -g) \
|
|
--volume /tmp/.X11-unix:/tmp/.X11-unix:rw \
|
|
--env DISPLAY=$DISPLAY \
|
|
anki "$@"
|
|
}
|
|
```
|