anki/docs/docker/README.md

119 lines
3.5 KiB
Markdown
Raw Normal View History

updates to the build process and binary bundles 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
2022-01-30 01:50:14 +01:00
# Building and running Anki in Docker
updates to the build process and binary bundles 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
2022-01-30 01:50:14 +01:00
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.
updates to the build process and binary bundles 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
2022-01-30 01:50:14 +01:00
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 "$@"
}
```