ARM Docker Image

[tomharvey]

Is your feature proposal related to a problem? Yes

When I use the docker image on my ARM based machine it ... is ... very ... slow.

Describe the solution you'd like to propose Build the image for ARM architecture

Maybe you can build cross platform from your workstation and continue to manually build-push the images to docker hub?

Might require some changes to the build pipeline - which I see in https://github.com/gboeing/osmnx/pulls you're already looking into - whereby a remote pipeline is used that is capable of building for both.

Describe alternatives you've considered

I've built an ARM version myself and I use that. So, I'm happy, but maybe there are others out there? I'm on ARM so checking out the repo and running docker build was enough.

Additional context

I sent you a https://twitter.com/alushtom/status/1557747027286564864 in case this isn't the best place.

Something like the below would build cross platofrm

docker buildx build --platform 'linux/amd64,linux/arm64,linux/arm/v7,linux/arm/v8' -t gboeing/osmnx .'

Some more info on that command https://www.docker.com/blog/faster-multi-platform-builds-dockerfile-cross-compilation-guide/

[gboeing]

I'm open to building for amd64 and arm64. However, when I looked into this in the past, I got an error running something simple like this on my linux machine:

>>> docker buildx build --platform linux/arm64 .
.buildkit_qemu_emulator: /bin/bash: Invalid ELF image for this architecture

As I don't have a personal use for this, I dropped it at that. If you want to open a PR with a simple change to get multi-platform working, I'm open to reviewing it.

[tomharvey]

I suspect that neither of us has the time, inclination or incentive to debug QEMU on your workstation.

Given that, how open are youto moving the build/push to a remote machine? GitHub actions would seem like the path of least resistance if you were open to that kind of setup. Then, any ~changes to master~ new tags could automatically build and push a new image.

If that’s worth exploring I can set that up on a fork for your review.

There are additional benefits in removing your workstation from the work flow too.

[gboeing]

Then, any new tags could automatically build and push a new image.

This could work. The reason I haven't done so in the past is that it takes an hour or more (it varies) for the new version to show up in conda's search index, which is necessary to build the docker image using the canonical OSMnx installation method. Hence, I just grab lunch then run a bash script when I get back.

[tomharvey]

Lol. Blasted reality.

Could still write the pipeline to run on GHA but trigger it manually with https://docs.github.com/en/actions/managing-workflow-runs/manually-running-a-workflow

Then, GitHub’s CPUs do the (multi platform) build but your after lunch activities remain pretty similar.

[gboeing]

Another option may be to include a linux sleep command at the beginning of the action, something like sleep 10800 to make it delay 3 hours before running.

[tomharvey]

I've raised a draft PR to see if you're OK with the direction taken.

include a linux sleep command

I don't ❤️ this approach ... and I doubt GitHub would thank you for consuming 3hrs of CPU time just sleeping.

Is there some kind of webhook/callback from conda once the package is updated?

If this was a full automated process, I wouldn't want to impose a manual step upon you, but using a manual build trigger isn't adding any additional work to you. We could script the manual trigger so you still only require the run of build.sh - just change the contents of that such that it calls GitHub actions instead of calling docker build...

[gboeing]

Thanks for exploring this further. I took a look at the PR, but I'm growing a bit leery of the complexity of this solution. I see the value in having a (sort of-) automated build for both arm and x64, but it creates more code and workflows that I must maintain. Technical debt remains a concern in projects like this. I'm growing inclined to suggest users build their own ARM images for now if they are needed. If there becomes a simpler way to do this in the future (ie, a simple workflow that "just works") I might reconsider it. And in the meantime, I may build and share an ARM image using my Mac.

[gboeing]

@tomharvey see the proposed fix in #869. I'm not sure if this solution will please you, but it's a lighter weight solution that results in amd64 and arm64 images. I agree with you it's probably important to support both architectures given where things are headed. Thanks again for flagging this and taking a first crack at it.

Using the code in the PR, I've pushed amd64 and arm64 images to Docker Hub: https://hub.docker.com/r/gboeing/osmnx/tags