Test or cull Docker support

[Julian-O]

Versions

• Buildozer: 2.2.0

Description

I have rumours from several sources to avoid Buildozer's Dockerfile.

The strongest version is from the (unofficial) Android-For-Python-Users:

There is an obsolete Docker image. DO NOT USE IT. The Docker image is not maintained.

However, it has every appearance of being supported:

• It is occasionally edited.
• It is documented.
• It is very, very lightly tested.
  • The test is simply to run buildozer --version.

If the rumour is true, and the Dockerfile is not being maintained:

• Remove the Dockerfile.
• Remove the vestigial test.
• Remove mentions from the documentation.
• Put a PR against the unofficial guide to update that advice.

I am happy to help if this is the direction wanted.

If the rumour is false, and the Dockerfile is being maintained, then let's demonstrate it clearly by running the test suite on Docker.

• Modify the test_python.yml (I can do this with some assistance, or someone else more au fait with docker commands can do it)
• Put a PR against the unofficial guide to update that advice.

[Julian-O]

#589 discusses the creation of a Docker image.

There is a Docker Image on DockerHub

In #1618 use of it is discouraged.

[Julian-O]

The Buildozer Action (see also #1747) depends on the Docker image, which is now years out of date, and causes it to have problems with Cython versions.

If the DockerHub image is to be supported, it should be upgraded and a Buildozer release checklist should include instructions on how to update it.

[misl6]

Android:

• python-for-android, have its own Dockerfile ( that we plan to support, and update the image soon on dockerhub )
• We can make buildozer to use this docker image while processing builds for Android. That will translate in fewer support requests and simplified install instructions.
• We should decide at this point if python-for-android via docker is the only option or if we want to continue support the non-dockerized version

iOS:

• kivy-ios can't have a docker image, as should run on macOS, and even if there are some success stories about a macOS docker image, the licensing of it is not quite clear.

macOS:

• Does not make sense to have a docker image (at least ATM), and as said for iOS, even if there are some success stories about a macOS docker image, the licensing of it is not quite clear.

Windows:

• No chances to use docker to build Windows artifacts

Linux:

• A Docker image for packaging Linux packages could be a nice option.

So, in replying to your question, I feel that a docker image could be something that buildozer uses to setup the target platform build environment (like https://github.com/pypa/cibuildwheel is doing when targeting Linux wheels).

The current buildozer Dockerfile just prepares an ( ATM outdated) environment that could be valid while targeting Android, and does not make a lot of sense since we have a python-for-android Docker image.

[Julian-O]

@misl6: I am hearing:

1. Update the DockerHub copy of python-for-android

2. Update the p4a release process to make sure it stays up-to-date.

3. Possibly: Come up with a way of publishing master and develop versions from CI builds onto Docker, so Buildozer can use them if required.

4. Remove buildozer\Dockerfile

5. Clearly deprecate (how?) the DockerHub copy.

6. Work on ArtemSBulgakov/buildozer-action: either help him fix it or develop a suitable replacement, because this will have a big impact.

7. Remove the the DockerHub copy.

8. Revamp buildozer to use docker (DockerHub?) images for Android (and Linux?)

   • Do so in a lower, platform-independent way, so Windows users can finally developer Android apps without WSL or VirtualBox - all the VM stuff is hidden from the user by Docker and Buildozer.

[misl6]

Yes, you heard it correctly.

(1) + (2) + (3) + (4): That could be easily done, and we can start working on it right now, so will be ready for the next python-for-android release.

(5): I would avoid deleting the image, as that looks destructive, but we can clearly state here in the README that the docker image is deprecated, and we can include a migration option.

(6): I will try to contact the author to propose working on a new version, hosted on kivy-garden/buildozer-action

(7): We really want to break old CI/CD pipelines that are using this old image? (maybe we can schedule to do that in x years?)

(8): That sounds like a good plan