All of the current callers follow the pattern:

    dockerPreRun(opts)
    err := dockerCli.Initialize(opts) ...

So there is no semantic change into merging the content of `dockerPreRun` into the head of `Initialize`.

I'm about to add a new caller outside of the `cmd/docker` package and this
seems preferable exporting `DockerPreRun`.

Signed-off-by: Ian Campbell <ijc@docker.com>

... and expose. I would like to use this from another site.

This implies also moving (and exposing) the `visitAll` helper.

Unit test them while I'm here.

Signed-off-by: Ian Campbell <ijc@docker.com>

I'm shortly going to add a second user to setup plugins, which will want to
reuse the common bits.

Signed-off-by: Ian Campbell <ijc@docker.com>

I'm shortly going to add a second user (plugins) which want to share some
behaviour.

Signed-off-by: Ian Campbell <ijc@docker.com>

This helps to avoid circular includes, by separating the pure data out from the
actual functionality in the cli subpackage, allowing other code which is
imported to access the data.

Signed-off-by: Ian Campbell <ijc@docker.com>

Signed-off-by: Ian Campbell <ijc@docker.com>

I authored this for `contentTrustEnabled` prior to 7f207f3, so this now
tests the funcation argument version.

Signed-off-by: Ian Campbell <ijc@docker.com>

That is, the helper to be used from the plugin's `main`.

Also add a `helloworld` plugin example and build integration.

Signed-off-by: Ian Campbell <ijc@docker.com>

Also includes the  scaffolding for finding a validating plugin candidates.

Argument validation is moved to RunE to support this, so `noArgs` is removed.

Signed-off-by: Ian Campbell <ijc@docker.com>

To help with this add a bad plugin which produces invalid metadata and arrange
for it to be built in the e2e container.

Signed-off-by: Ian Campbell <ijc@docker.com>

To do this we add a stub `cobra.Command` for each installed plugin (only when
invoking `help`, not for normal running).

This requires a function to list all available plugins so that is added here.

Signed-off-by: Ian Campbell <ijc@docker.com>

e.g. the `docker` case which should act as `docker help`.

Signed-off-by: Ian Campbell <ijc@docker.com>

Signed-off-by: Ian Campbell <ijc@docker.com>

To achieve this we hook in at the beginning of our custom `HelpFunc` and detect
the plugin case by adding stub commands.

Signed-off-by: Ian Campbell <ijc@docker.com>

Previously a plugin which used these hooks would overwrite the top-level plugin
command's use of this hook, resulting in the dockerCli object not being fully
initialised.

Provide a function which plugins can use to chain to the required behaviour.
This required some fairly ugly arrangements to preserve state (which was
previously in-scope in `newPluginCOmmand`) to be used by the new function.

Signed-off-by: Ian Campbell <ijc@docker.com>

Signed-off-by: Ian Campbell <ijc@docker.com>

Fairly straight forward. It became necessary to wrap `Plugin.Err` with a type
which implements `encoding.MarshalText` in order to have that field rendered
properly in the `docker info -f '{{json}}'` output.

Since I changed the type somewhat I also added a unit test for `formatInfo`.

Signed-off-by: Ian Campbell <ijc@docker.com>

Signed-off-by: Ian Campbell <ijc@docker.com>

Signed-off-by: Ian Campbell <ijc@docker.com>

On Windows `foo.exe`, `foo.eXe` and `foo.EXE` are equally executable.

Signed-off-by: Ian Campbell <ijc@docker.com>

This allows passing argument to plugins, otherwise they are caught by the parse
loop, since cobra does not know about each plugin at this stage (to avoid
having to always scan for all plugins) this means that e.g. `docker plugin
--foo` would accumulate `plugin` as an arg to the `docker` command, then choke
on the unknown `--foo`.

This allows unknown global args only, unknown arguments on subcommands (e.g.
`docker ps --foo`) are still correctly caught.

Add an e2e test covering this case.

Signed-off-by: Ian Campbell <ijc@docker.com>

A static global initialiser happens before the arguments are parsed, so we need
to calculate the path later.

Signed-off-by: Ian Campbell <ijc@docker.com>

They were listed twice in `docker --help` (but not `docker help`), since the
stubs were added in both `tryRunPluginHelp` and the `setHelpFunc` closure.

Calling `AddPluginStubCommands` earlier in `setHelpFunc` before the call to
`tryRunPluginHelp` is sufficient. Also it is no longer necessary to add just
valid plugins (`tryRunPluginHelp` handles invalid plugins correctly) so remove
that logic (which was in any case broken for e.g. `docker --help`).

Update the e2e test to check for duplicate entries and also to test `docker
--help` which was previously missed.

Signed-off-by: Ian Campbell <ijc@docker.com>