Handle empty `.srcd` when other commands are executed before `install`

[carlosms]

Handle empty .srcd when other commands are executed before install:

$ rm -rf ~/.srcd
$ sandbox-ce stop
chdir /home/cmartin/.srcd/workdirs/__active__: no such file or directory

[dpordomingo]

Can we assume that if there's no ~/.srcd, there is no running sandbox?
Maybe we can't.

If ~/.srcd is deleted after sourced install, the ui is still working, but prune, stop, status commands no longer work, so you need to install again.

What should be the expected behavior?

could it be a good idea to store the "active" config in a volume?

[carlosms]

Can we assume that if there's no ~/.srcd, there is no running sandbox?
Maybe we can't.

If ~/.srcd is deleted after sourced install, the ui is still working, but prune, stop, status commands no longer work, so you need to install again.

What should be the expected behavior?

If the user deletes files we need, I don't think is reasonable to be able to recover.
A user that feels confident enough to delete this dir should also be able to fix anything with plain docker commands.

could it be a good idea to store the "active" config in a volume?

I don't see much benefit for the extra complexity.

[dpordomingo]

Then, I don't know if we should put that "critical" data in user's home instead of in more internal app directory (like /var/srcd or ~\AppData\Local).

Anyhow.
what should be the behavior if the users run sourced status with no ~/.srcd?

• inform the users about no available sandbox? (what can be false in some examples)
• recommend them running install before running status? (what would also fix prev example)
• other...

[carlosms]

Then, I don't know if we should put that "critical" data in user's home instead of in more internal app directory (like /var/srcd or `~\AppData\Local).

Moving things to /var makes sense to me.

what should be the behavior if the users run sourced status with no ~/.srcd?

• inform the users about no available sandbox? (what can be false in some examples)
• recommend them running install before running status? (what would also fix prev example)
• other...

I would forget about the case where the user might be deleting files, it's outside of our control.

To me the reasonable output for status, stop etc. would be something along the lines of
cannot perform this action, source{d} needs to be initialized first with the 'install' sub command

[dpordomingo]

Since running install again will also fix the described problem, lgtm.