Prune should delete active workdir

[smacker]

Currently, there is no way to delete workdir except manually rm -rf directory.
I think prune should delete everything including workdir.

Also right now it's possible to run prune multiple times. On the second time it prints:

Removing network srcd-2ac536d6a6bb44bab48c58b1797bcafe76bd6ef0_default
WARNING: Network srcd-2ac536d6a6bb44bab48c58b1797bcafe76bd6ef0_default not found.
Removing volume srcd-2ac536d6a6bb44bab48c58b1797bcafe76bd6ef0_gitbase_indexes
WARNING: Volume srcd-2ac536d6a6bb44bab48c58b1797bcafe76bd6ef0_gitbase_indexes not found.
Removing volume srcd-2ac536d6a6bb44bab48c58b1797bcafe76bd6ef0_postgres
WARNING: Volume srcd-2ac536d6a6bb44bab48c58b1797bcafe76bd6ef0_postgres not found.
Removing volume srcd-2ac536d6a6bb44bab48c58b1797bcafe76bd6ef0_redis
WARNING: Volume srcd-2ac536d6a6bb44bab48c58b1797bcafe76bd6ef0_redis not found.

Yes/No?

[dpordomingo]

Agree on the first part:

I think prune should (also) delete the workdir.

But I'd recommend avoiding it being the default behavior in case it's expected (or a feature), that the user could modify workdir docker-compose.yml. If it's a feature (and reading our docs, it is), I'd avoid deleting it without explicit action from the user.

About the second part, I'd suggest to consider it as a separate issue.
From my pov, it's because sourced is a plain wrapper over docker-compose, who also behaves that way when running docker-compose down --volumes many times.
I'd also like to improve that plain wrapper to enhance the UX, but imo it should be discussed separately..
(e.g. that plain wraper design, also causes this other #35)

[carlosms]

👍 To me it makes sense to remove the dir in ~/.srcd/workdirs.
After a prune you lose the volumes, so it doesn't make sense to have them listed in sourced workdirs.

But I'd recommend avoiding it being the default behavior in case it's expected (or a feature), that the user could modify workdir docker-compose.yml. If it's a feature (and reading our docs, it is), I'd avoid deleting it without explicit action from the user.

In ~/.srcd/workdirs each docker-compose.yml is a symlink to ~/.srcd/compose-files/__active__/docker-compose.yml. As a user you can manage docker compose files with sourced compose, or tinkering with the files in ~/.srcd/compose-files.

One important detail to keep in mind: workdirs can be nested, we have to be careful to not delete subdirs

$ go run cmd/sourced/main.go workdirs
  /home/cmartin/repos
* /home/cmartin/repos/gitbase

[dpordomingo]

In our docs we say:

you can explore the contents of your ~/.srcd directory. There you will find a docker-compose.yml and .env files for each set of repositories used by sourced init

I understand, that we're offering the ability to use your own modified docker-compose.yml per workdir, so maybe removing it on prune, can be a bad idea if the user is not really aware.

Maybe:

It was detected a custom version of `docker-compose.yml` in `/path/to/workdir`.
Do you want to keep it? [y]/n

[carlosms]

Let's please not over complicate the CLI accommodating all possible scenarios.

[dpordomingo]

Since its a feature to let the users use and modify their own docker-compose.yml, I think we should clearly document that prune will also the workdir under user's home.

[carlosms]

Since its a feature to let the users use and modify their own docker-compose.yml, I think we should clearly document that prune will also the workdir under user's home.

I don't think we should consider users tinkering with docker-compose.yml files in workdir a feature. We have a command for that, sourced compose.