No way to not remove depended on services with `docker compose rm`

[richardxia]

Description

The behavior of docker compose rm differs from docker-compose rm in how dependent services are handled. Previously, docker-compose rm <service> would only attempt to remove the specified service, but, docker compose rm <service> will attempt to remove the specified service and all other services it depends on.

Steps to reproduce the issue:

1. Suppose you have two services, a web application service (app) and a database service (db), where the web application depends on the database service via the depends_on property in docker-compose.yml.
2. Run docker compose up to create the containers and initialize the database.
3. Hit Ctrl+C to stop the containers.
4. Run docker compose rm app.

Describe the results you received:

Both app and db are removed. Also, because db is removed, any anonymous volumes, such as ones holding the actual database data, are removed.

Describe the results you expected:

Only app is removed.

Additional information you deem important (e.g. issue happens only occasionally):

This is a surprising change in behavior compared to the old docker-compose CLI. Yes, it did prompt me with a confirmation about the containers being removed, but because I was used to the old behavior, I entered Y out of habit. This is particularly annoying in my case because my database service is just the vanilla, official Postgres Docker image, which defines an anonymous volume holding the actual database data, and removing the db service caused the volume to be removed. Nothing critical was lost in my case, since it was just a development database, but it is a bit frustrating to lose it.

Also, until I encountered this, I had no idea that docker compose was a separate command-line program than docker-compose and that they would have different behavior. I really think the Docker for Mac release notes and messages from docker-compose that tell you to instead use docker compose should make it clearer that these two tools are different so that users will understand that they may need to be careful about any specific behavior that they were used to.

As far as I can tell, there is no way to remove just the app service and not the other services it depends on, since I don't see any documented options for doing so, so until then, I think I will have to continue using docker-compose rm.

Output of docker version:

Client: Docker Engine - Community
 Cloud integration: 1.0.12
 Version:           20.10.5
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        55c4c88
 Built:             Tue Mar  2 20:13:00 2021
 OS/Arch:           darwin/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.5
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       363e9a8
  Built:            Tue Mar  2 20:15:47 2021
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.4
  GitCommit:        05f951a3781f4f2c1911b05e61c160e9c30eaa8e
 runc:
  Version:          1.0.0-rc93
  GitCommit:        12644e614e25b05da6fd08a38ffa0cfe1903fdec
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Output of docker context show:
You can also run docker context inspect context-name to give us more details but don't forget to remove sensitive content.

default

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Build with BuildKit (Docker Inc., v0.5.1-docker)
  scan: Docker Scan (Docker Inc., v0.6.0)

Server:
 Containers: 6
  Running: 1
  Paused: 0
  Stopped: 5
 Images: 130
 Server Version: 20.10.5
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: io.containerd.runtime.v1.linux runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 05f951a3781f4f2c1911b05e61c160e9c30eaa8e
 runc version: 12644e614e25b05da6fd08a38ffa0cfe1903fdec
 init version: de40ad0
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 5.10.25-linuxkit
 Operating System: Docker Desktop
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 3.843GiB
 Name: docker-desktop
 ID: 2QMH:ULW3:DZ3R:MCSR:U3QD:5KS3:DJ2H:TI65:PIHH:MLF7:GO45:QYRH
 Docker Root Dir: /var/lib/docker
 Debug Mode: true
  File Descriptors: 58
  Goroutines: 71
  System Time: 2021-04-19T18:12:08.1570176Z
  EventsListeners: 3
 HTTP Proxy: http.docker.internal:3128
 HTTPS Proxy: http.docker.internal:3128
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details (AWS ECS, Azure ACI, local, etc.):