Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dockerfile versioning #278

Closed
robertmartin8 opened this issue Feb 13, 2021 · 2 comments · Fixed by #299
Closed

Dockerfile versioning #278

robertmartin8 opened this issue Feb 13, 2021 · 2 comments · Fixed by #299
Labels
packaging A problem with installation, dependencies, versioning

Comments

@robertmartin8
Copy link
Owner

@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.

@robertmartin8 robertmartin8 added the packaging A problem with installation, dependencies, versioning label Feb 13, 2021
@phschiele
Copy link
Contributor

@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
Copy link
Owner Author

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!

@robertmartin8 robertmartin8 mentioned this issue Feb 19, 2021
@robertmartin8 robertmartin8 linked a pull request Feb 19, 2021 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
packaging A problem with installation, dependencies, versioning
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants