Add Dockerfile and compose config for testing

[spwoodcock]

Included

• I didn't want to install Java on my system, so created a quick docker setup for running the tests.
• I added to the contrib dir to make it clear that this is not maintained by the authors, but thought it could be useful to some (perhaps included in the docs?).
• The included dockerfile installs all dev dependencies, but could be easily extended to only install production dependencies in a stage, then used for a repository image to distribute pyxform: e.g. ghcr.io/xlsform/pyxform.
• I used this setup for testing in PR Allow passing BytesIO objects to xls2xform_convert #698

Why is this the best possible solution? Were any other approaches considered?

• A did base this on Python 3.10, while the repo only states 3.7-3.9 are supported.
• I use pyxform without issues in a project based on Python 3.10.
• Python 3.7 is EOL, 3.8 will be EOL in about 0.5yr and 3.9 EOL in about 1.5yr.

What are the regression risks?

• None

Does this change require updates to documentation? If so, please file an issue here and include the link below.

• Could possibly be included in the docs about testing, if useful.
• Simply run docker compose -f contrib/images/docker-compose.yml run --rm pyxform to run the tests.
• Or docker compose -f contrib/images/docker-compose.yml run --rm pyxform -k test_xls2form_convert_via_api for a specific test.
• Or docker run -i ghcr.io/xlsform/pyxform:ci --help to use the xlsform CLI tool.

Before submitting this PR, please make sure you have:

• included test cases for core behavior and edge cases in tests
• run python -m unittest and verified all tests pass
• run ruff format pyxform tests and ruff check pyxform tests to lint code
• verified that any code or assets from external sources are properly credited in comments

[lindsay-stevens]

Please have a look at my comment here on contributing to pyxform.

The current pyxform development processes do not use Docker by default. For a potential new contributor there are substantially less pitfalls involved in installing a JRE, compared to standing up Docker and/or Compose, let alone understanding how to use these effectively in a development context. We would need to at least mention in the README how to use them. It may be more appropriate to publish Docker files in a separate repository, as has been done here by another ODK team member.

In relation to supported python versions, there is an issue here to address that and it's at the top of the "Next" milestone here - meaning it will be worked on very soon.

[spwoodcock]

I won't dispute that installing a JRE is pretty easy, but would argue that installing Docker and Compose are not that much more complex. In a couple of commands you can have things working.

The config is aimed at developers, specifically for testing.
What if I am a Java developer requiring multiple runtimes for different projects?
Docker makes this type of setup easy.
I would say 'new contributor' does not necessarily mean 'new developer', so it's nice if the setup can be as flexible as possible.

Either way, would it be worth linking the docker configuration in the docs here?
I had no idea it existed & would have happily contributed to that repo!
(although note within that repo it would only be a Dockerfile specifically for using pyxform, not for running tests).

[lognaturel]

installing Docker and Compose are not that much more complex

A few years ago we had a lot more Dockerfiles for dev but we scaled it back because we found we often forgot to update them and that we preferred not having to manage a Docker daemon on our machines and make sure we had enough memory and disk space for other things. The latter has gotten somewhat better with Orbstack but I think we're all still feeling a little burned and use other tools for dev environment management (nix, jenv, etc). This is definitely a team culture kind of thing.

How about putting your dockerfile in a repo and we'll link to it from the readme? I have a proposed structure for this that I'll put a PR up for in a moment.