Skip to content

Conversation

@StefanScherer
Copy link
Member

- What I did

On Windows also search for CLI plugins in the C:\Program Files\Docker\cli-plugins folder.
This would simplify the installation of the docker.zip file with the PowerShell module via the DockerMsftProvider or DockerProvider. They both just unzip the file into C:\Program Files
We only have to put the CLI plugins in the zip into docker/cli-plugins/ and they will be just right in place.

- How I did it

- How to verify it

- Description for the changelog

On Windows also search for CLI plugins in the C:\Program Files\Docker\cli-plugins folder.

- A picture of a cute animal (not mandatory but encouraged)

IMG_5280

Copy link
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

ping @ijc

Copy link
Contributor

@ijc ijc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

The way you have it ProgramFiles will take priority over ProgramData, so if you install the same plugin in both the one in ProgramFiles will be used. Is that correct for Windows/what a Windows user would expect? (nb: I have no reason to think that is wrong or right since I don't know Windows well enough, just wanted to ask the Q)

@StefanScherer
Copy link
Member Author

@ijc A good question. I don't have a hard preference, it looked plausible for me to put ProgramFiles in front as a Windows Server installation has the plugins there.

There always is another user specific folder that is searched, so the order would be

  1. $env:USERPROFILE/.docker/cli-plugins
  2. $env:ProgramFiles/Docker/cli-plugins
  3. $env:ProgramData/Docker/cli-plugins

Any concerns from the Desktop side about this order?

@thaJeztah
Copy link
Member

Perhaps swap 2 and 3 (as in "ProgramFiles" feels more like a default location where things are installed, and "ProgramData" more "runtime", thus "override"; this post seems to confirm that https://stackoverflow.com/a/27497662/1811501)

Signed-off-by: Stefan Scherer <stefan.scherer@docker.com>
@StefanScherer StefanScherer force-pushed the windows-programfiles-docker-cli-plugins branch from 98e102c to 4d3a76d Compare March 20, 2019 18:46
@codecov-io
Copy link

Codecov Report

Merging #1760 into master will decrease coverage by 0.05%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #1760      +/-   ##
==========================================
- Coverage   56.32%   56.27%   -0.06%     
==========================================
  Files         307      307              
  Lines       21177    21151      -26     
==========================================
- Hits        11928    11902      -26     
  Misses       8382     8382              
  Partials      867      867

@StefanScherer
Copy link
Member Author

@thaJeztah All right, I've swapped the two pathes to have ProgramData before ProgramFiles

@thaJeztah
Copy link
Member

LGTM, thanks!

@tiborvass tiborvass merged commit 774d78f into docker:master Mar 20, 2019
@GordonTheTurtle GordonTheTurtle added this to the 19.03.0 milestone Mar 20, 2019
@StefanScherer StefanScherer deleted the windows-programfiles-docker-cli-plugins branch March 20, 2019 21:05
@gtardif
Copy link
Contributor

gtardif commented Mar 21, 2019

Yes, This will help a bit as well for Desktop Enterprise to allow deploy plugins either in Program Files or ProgramData. (no preference between the 2 or on the order)

@ijc
Copy link
Contributor

ijc commented Mar 21, 2019

All right, I've swapped the two pathes to have ProgramData before ProgramFiles

If we assume that "packaged" installs will generally statically installing things in ProgramFiles then that makes sense I think, it leaves ProgramData for "system level overrides" (be that ones done by the admin or ones done by applications dynamically somehow), the "user level overrides" in %HOME% still take overall precedence, which is good.

Still LGTM then!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants