3 ms·

> CLI usability is close to zero What? > One (temp) image per line in the Dockerfile might have some practical uses, but most of the time it doesn't. I compl

by pknopf 8y ago

> CLI usability is close to zero What? > One (temp) image per line in the Dockerfile might have some practical uses, but most of the time it doesn't. I completely disagree. Cached builds being one reason, viewing the intermediate layers is just a huge benefit. Why don't you like it. You could always build with "--no-cache", which all CI should be using anyway.

raverbashing 8y ago
> What? Yes. It's all over the place. https://docs.docker.com/engine/reference/commandline/cli/ https://docs.docker.com/engine/reference/commandline/cli/ It has no obvious separation of commands dealing with images/containers/running containers. Sometimes you refer to them by tags, sometimes by IDs. It's non discoverable. It's non intuitive. I can't know what 'docker rm' does without reading the docs. Oh and there is 'docker rmi' is that for images? Docker build has this nice example here: '--tag , -t Name and optionally a tag in the ‘name:tag’ format' Ok so you set a name with --tag? Compare with 'kubectl get pods' > Cached builds being one reason, viewing the intermediate layers is just a huge benefit. Sure, as I said, it is useful, but you do not want to do this most of the time. > You could always build with "--no-cache", which all CI should be using anyway. Bad defaults are an UX problem, thanks for furthering my point.
- declnz 8y ago
  >It's non discoverable. It's non intuitive. > I can't know what 'docker rm' does without reading the docs. Oh and there is 'docker rmi' is that for images? I think you're using the old CLI. A couple of years ago, they added new syntax and "encouraged" its use by default [1] (though IME people still use the original). This is definitely more discoverable and logical; the syntax would be `docker image rm` [2] or `docker container rm` [3], etc [1] https://blog.docker.com/2017/01/whats-new-in-docker-1-13/ https://blog.docker.com/2017/01/whats-new-in-docker-1-13/ [2] https://docs.docker.com/engine/reference/commandline/image_rm/ https://docs.docker.com/engine/reference/commandline/image_r... [3] https://docs.docker.com/engine/reference/commandline/container_rm/ https://docs.docker.com/engine/reference/commandline/contain...
  - raverbashing 8y ago
    Interesting, I used it last year, but I'd say it could have been an older version. Thanks for pointing this, and I'm glad they realized the issue as well!

by pknopf 8y ago

raverbashing 8y ago

> What? Yes. It's all over the place. https://docs.docker.com/engine/reference/commandline/cli/ https://docs.docker.com/engine/reference/commandline/cli/ It has no obvious separation of commands dealing with images/containers/running containers. Sometimes you refer to them by tags, sometimes by IDs. It's non discoverable. It's non intuitive. I can't know what 'docker rm' does without reading the docs. Oh and there is 'docker rmi' is that for images? Docker build has this nice example here: '--tag , -t Name and optionally a tag in the ‘name:tag’ format' Ok so you set a name with --tag? Compare with 'kubectl get pods' > Cached builds being one reason, viewing the intermediate layers is just a huge benefit. Sure, as I said, it is useful, but you do not want to do this most of the time. > You could always build with "--no-cache", which all CI should be using anyway. Bad defaults are an UX problem, thanks for furthering my point.

declnz 8y ago
>It's non discoverable. It's non intuitive. > I can't know what 'docker rm' does without reading the docs. Oh and there is 'docker rmi' is that for images? I think you're using the old CLI. A couple of years ago, they added new syntax and "encouraged" its use by default [1] (though IME people still use the original). This is definitely more discoverable and logical; the syntax would be `docker image rm` [2] or `docker container rm` [3], etc [1] https://blog.docker.com/2017/01/whats-new-in-docker-1-13/ https://blog.docker.com/2017/01/whats-new-in-docker-1-13/ [2] https://docs.docker.com/engine/reference/commandline/image_rm/ https://docs.docker.com/engine/reference/commandline/image_r... [3] https://docs.docker.com/engine/reference/commandline/container_rm/ https://docs.docker.com/engine/reference/commandline/contain...
- raverbashing 8y ago
  Interesting, I used it last year, but I'd say it could have been an older version. Thanks for pointing this, and I'm glad they realized the issue as well!