Open carlosperate opened 1 year ago
A current workaround could be to mount the local mu repository in a subdirectory (/home/mu
instead of /home
), and call the pup command from the parent folder (/home
), so that the build folder (/home/build
) does not end up in the directory mounted from the host:
docker run -v $(pwd):/home/mu --rm ghcr.io/mu-editor/mu-appimage:2022.05.01 bash -c "\
cd mu && \
pip install .[dev] && \
python -m mu.wheels --package && \
cd .. &&
python -m virtualenv venv-pup && \
./venv-pup/bin/pip install pup && \
./venv-pup/bin/pup package --launch-module=mu --nice-name='Mu Editor' --icon-path=./mu/mu/resources/images/icon.png --license-path=./mu/LICENSE mu/ && \
ls -la dist/ && \
mv dist mu/dist"
This is because when using docker to build an AppImage for Mu, if we mount the Mu repository from the host (in my case macOS) as a volume inside the docker container (so that it can be build using
docker run...
commands), it fails to build the AppImage.To illustrate the issue:
The pup output is:
However, by changing the build directory set in this file, to a different path not monted from the host (for example from
build
to/build
), and running the same steps in a container bash session works. (And just to double check, running the original unmodified steps in a docker container bash session does fail the same way).https://github.com/mu-editor/pup/blob/55bf81d7f5395910639ad384dd0db8665bc2ea2b/src/pup/plugins/dirs.py#L8-L11
I'm not 100% what the issue might be, but I woudn't be surprised if AppImageBuildKit (or whatever the build engine is) is trying to create symlinks and that somehow fails as the thing it point to does not exist in the host OS filesystem.
So, if we could have a
--build-dir
flag (or similarly named), we could avoid this issue and add a new Makefile target in the Mu project to build an AppImage using docker.