Dockerfile versioning

[robertmartin8]

@phschiele following up from #274

Docker is supported for a couple of reasons:

• As a worst case, if a user is really not able to get anything installed on their machine, running it in a docker container should work
• Binder support. This serves the cookbook jupyter notebooks so people can try stuff in browser. I personally find it very useful if I want to run some very quick tests in response to a new issue (rather than opening my IDE, activating the venv, opening jupyter notebook etc).
• Advanced users who are used to running everything from containers may find it useful.

I agree that using poetry in the dockerfile is the most consistent solution, but I wonder if that adds unnecessary overhead. People use docker containers as an alternative to virtualenvs, so it might be an unnecessary layer of complexity to have poetry inside.

I think the best compromise is to fix the dependency specification in requirements.txt (as we are discussing in #277) then leave docker as is.

[phschiele]

@robertmartin8 The use cases you describe make total sense to me.

I agree that updating the requirements.txt will already be an improvement.

One reason why I particularly like poetry in combination with Docker is reproducibility. Note that with requirements.txt, the sub dependencies might change when running the same Dockerfile twice, which can lead to problems in edge cases.
Of course, poetry does not remove all such issues, but by locking all the sub dependencies, the risk is greatly reduced.
Additionally, I think as long as the Dockerfile is working reliably, most users would not really care if it is using requirements.txt or poetry under the hood.

If that sounds interesting to you, I can open a PR so you can try it for yourself.

[robertmartin8]

as long as the Dockerfile is working reliably, most users would not really care if it is using requirements.txt or poetry under the hood.

Yeah this is probably right. If you've got time, a PR would be much appreciated!