Absolutely LGTM on design, 🎉, 💯, etc.

My only nit, but I won't fight for it, is that I'm skeptical about the need for short aliases (docker con, docker vol, etc.).

docker con

Not big on the short aliases, but I like the thought for everything else.

Not a huge fan of short aliases but other than that, just like @icecrime, absolutely LGTM on design 😎 🎉

My rational for the short aliases is this:

It's going to be difficult to convince people to use docker container rm instead of docker rm. It's just much longer to type. Adding the short aliases make the situation a lot better because it's just 3 extra characters, instead of 9!

If we don't make it easy to use the new canonical commands we're never going to be able to remove them.

You think we'll be able to remove something like docker rm or docker run? I doubt that.

docker run no, we aren't even hiding it, it's staying as a permanent alias.

The rest, not any time soon. Maybe in a year or two if we're good about converting all the docs to the new form, and communicating the new canonical way of doing things.

I love this, but if we do it, we should take this chance to fix the output of inspect to default to be pretty and composite. This was a HUGE point of contention during the implementation of swarm services. Making inspect output text composed of multiple API calls will address this problem and let us really grow the usability of inspect, while addressing long standing issues.

My rational for the short aliases is this:
It's going to be difficult to convince people to use docker container rm instead of docker rm. It's just much longer to type.

Realistically people won't do that though, they'll type docker c<tab> rm. As long as the completion is the full "container" (i.e. "con" isn't an entry) it wouldn't bother me, but for this reason I don't think it's necessary.

we should take this chance to fix the output of inspect to default to be pretty and composite

I'm not sure that we can change inspect, but we could definitely introduce a new command that defaults to pretty print, and hide inspect from help. Do you know if there is an issue with a proposal for that change? I'd like to keep that discussion and change separate from this PR.

Realistically people won't do that though, they'll type docker c rm. As long as the completion is the full "container" (i.e. "con" isn't an entry) it wouldn't bother me, but for this reason I don't think it's necessary.

My 2c -- I'm not really a fan of completion on subcommands, since it requires that you install and maintain additional completion scripts instead of being something that works out of the box. In docker container's case as well, keep in mind that it's competing with docker commit and others for the same completion, so by the time you've typed enough characters to differentiate container for completion, you've already typed docker con anyway.

I wouldn't really like to see docker ps go away pretty much ever since it is such deeply ingrained habit for me, is extremely short and frequently invoked and I don't really mind having porcelain around the "true" commands (git style, i.e. "every command is just a wrapper around rebase"). But I understand the motivation.

I'd definitely like to see more elaboration around where we draw the lines here, e.g., why would it be OK for docker service scale foo=3 to alias to docker service update --replicas 3 foo (porcelain wrapper like mentioned above) but not OK for docker ps to alias to docker container ls.

I'm not sure that we can change inspect, but we could definitely introduce a new command that defaults to pretty print, and hide inspect from help. Do you know if there is an issue with a proposal for that change? I'd like to keep that discussion and change separate from this PR.

Not that I know of. File away or ping me again and I'll cook something up.

I agree that this shouldn't be a part of this PR, if we frame it that way.

This is now rebased, and no longer hides the commands. It only adds the new canonical commands.

Just discussed with @dnephin that we're gonna do docs (and completion scripts) in a follow-up PR. I'll open a tracking issue

And, it's green!

LGTM !

👏

Is there any chance of differentiating between Legacy|old|standalone Swarm and "Swarm Mode" at least in the doc. For instance:

Management Commands:
  ...
  node        Manage Docker Swarm mode nodes
  service     Manage Docker services
  swarm       Manage Docker legacy Swarm
  ...

The old vs new swarm is a recurring area of misunderstanding over at Stackoverflow and elsewhere. The "swarm mode" should really have been named something else in my opinion. Sorry to bring this up here but since we're stuck with "Swarm" I would love the doc to at least acknowledge that it's dealing with two different technologies and use some naming to help distinguish them.

@gittycat docker swarm is not the legacy swarm, it's the new "swarm mode". Only swarm is the old swarm, which is not available through this CLI.

@gittycat Rule of thumb: if there is a docker in front of your command, you're probably using Swarm-mode.

I usually refer to them as "Docker Services" for clarification.

ping @sdurrheimer there's a lot of work waiting for you here 😰, PTAL

@albers I see 😲, thx for the ping.

kudos!

i was actually using custom make scripts to do just this with almost equal commands!!!

thanks for standardizing in 1.13! saved me from opening a ticket =)