Closed NicolasCARPi closed 2 years ago
Yes you're correct. In fact in my mind using docker automatically assumes using docker-compose because running commands directly seems barbaric to me!! :p
I still think it's necessary to include it because you can never have enough documentation and assuming users will "figure things out by themselves" doesn't sound like a very developer friendly approach, even if I agree it didn't take me long to figure it out, but I'm very familiar with the whole thing and thus not necessarily representative of the potential dev userbase.
I'll push some commits later and try and include what you mention about flask debug and the demo script.
I'm only semi-barbaric then, as I usually run those Docker commands from Makefiles. ;)
My line of thinking was that users who need the instructions should follow the instructions and workflow provided. But yes, a Docker-based alternative won't hurt, as long as it includes enough instructions/steps to be useful. Thanks!
… “semi-barbaric," then what do you call people who write little (or hardly any) documentation?
On 20. Apr 2022, at 07:54, Florian Rhiem @.***> wrote:
I'm only semi-barbaric then, as I usually run those Docker commands from Makefiles. ;)
My line of thinking was that users who need the instructions should follow the instructions and workflow provided. But yes, a Docker-based alternative won't hurt, as long as it includes enough instructions/steps to be useful. Thanks!
— Reply to this email directly, view it on GitHub https://github.com/sciapp/sampledb/pull/34#issuecomment-1103498630, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABLUBZDJHYQIOO6W472BRF3VF6LZDANCNFSM5TWCJNGQ. You are receiving this because you are subscribed to this thread.
I pushed a commit addressing the comments, let me know what you think. :)
Thank you for the additional documentation on the Docker Compose workflow!
As a side note, I think it would be good to have a --force
flag on the demo script so it can overwrite the db directly, even if it's not empty (by emptying first of course).
That is currently part of demo.py, along with the auto login, etc., but sure it could be part of the set_up_demo
script if a --force
flag was provided.
The current text might confuse readers, as the change described only makes sense when using Docker Compose instead of using Docker directly, a workflow not recommended or even described in the text. Personally I would assume that someone who decides to go with that workflow is very likely to figure out that last step of mounting the directory by themselves. So I think this should be left out. Alternatively, this Docker Compose based workflow could be described as an alternative to the virtual environment based workflow, but then other steps such as using the flask development server in debug mode and running set_up_demo script (currently both are done in demo.py) should also be included in the workflow description.