When running ersilia delete eosxxxxx, where eosxxxxx was fetched using its Docker image, if ersilia finds that the Docker engine is not running on the user's machine, it silently exits. In the ideal case, we expect the image to be deleted, however whether or not the engine is active on the user's system, is out of our control. Nonetheless, we need to flag this at the very least and raise a message to user asking them to start docker engine on their system and then run this command.
There is another solution to this that's a bit more robust and upfront: We could utilize the model source information in the model bundle, determining how the model was fetched in the very beginning of the delete command invocation. If it was fetched using DockerHub, we should check whether the engine is running and flag that to the user upfront, instead of deleting things halfway, checking whether the engine is running or not, and then raising this error. In this case, we can prompt the user to start their docker engine and re-invoke the delete command.
In both cases, if the engine is not running, the user would have to start it and re-run the command, however in the second approach, the model wouldn't end up dangling in a half fetched, half not fetched state where model directories are deleted, but the image persists. I prefer this solution, however I am open to suggestions from a usability point of view.
Summary
Refer to the issue
When running
ersilia delete eosxxxxx
, where eosxxxxx was fetched using its Docker image, if ersilia finds that the Docker engine is not running on the user's machine, it silently exits. In the ideal case, we expect the image to be deleted, however whether or not the engine is active on the user's system, is out of our control. Nonetheless, we need to flag this at the very least and raise a message to user asking them to start docker engine on their system and then run this command.There is another solution to this that's a bit more robust and upfront: We could utilize the model source information in the model bundle, determining how the model was fetched in the very beginning of the delete command invocation. If it was fetched using DockerHub, we should check whether the engine is running and flag that to the user upfront, instead of deleting things halfway, checking whether the engine is running or not, and then raising this error. In this case, we can prompt the user to start their docker engine and re-invoke the delete command.
In both cases, if the engine is not running, the user would have to start it and re-run the command, however in the second approach, the model wouldn't end up dangling in a half fetched, half not fetched state where model directories are deleted, but the image persists. I prefer this solution, however I am open to suggestions from a usability point of view.
Thoughts @miquelduranfrigola @GemmaTuron?
Objective(s)
No response
Documentation
No response