Build Windows Docker Image That is Usable for Testing

[insertinterestingnamehere]

The main blockers for this are https://github.com/Anaconda-Server/anaconda-build/issues/273 and https://github.com/Anaconda-Server/anaconda-build/issues/274. Once those are done, we can fill in any additional gaps to provide a working container for running tests on Windows.

[stephenakearns]

Stretch goal for the 1.15.1 milestone.

[insertinterestingnamehere]

Here's a draft. This has pretty much everything I can get on there. Most of the remaining issues need fixing upstream.

FROM windowsservercore
WORKDIR C:/Users/Administrator
# Specifying the user like this could, theoretically,
# fix some of the installation/menu problems 
# USER Administrator

# Use custom miniconda installer that does not add shortcuts or modify path.
# This installer should be built using conda constructor to get a miniconda-like
# installer that has
# https://github.com/conda/constructor/blob/f0cb8979d9e64f34013385608424be90432f253f/constructor/nsis/main.nsi.tmpl#L470-L472
# commented out so that the broken menu installation doesn't
# freeze the installation process.
# The freezing installer is likely caused by
# https://github.com/docker/docker/issues/22169
# Here we need to use unix-style paths to specify the target location.
# Windows style paths don't work for some reason.
# See https://github.com/docker/docker/issues/21697
ADD ./miniconda3_custom.exe /Users/Administrator/miniconda3_custom.exe
# Install miniconda
# The `| more` idiom makes cmd wait for the command to finish.
# Some installers return an exit code after launching sucessfully,
# not after completing sucessfully.
RUN miniconda3_custom.exe /S /D=C:\Users\Administrator\miniconda3 | more

# This shows how this can be done once the normal installer works properly in a container.
# Get and install the latest miniconda3 installer.
#RUN powershell -Command " \
#    $url = \"https://repo.continuum.io/miniconda/Miniconda3-latest-Windows-x86_64.exe\"; \
#    $client = new-object System.Net.WebClient; \
#    $client.DownloadFile( $url, \"miniconda3.exe\"); \
#    "
#RUN miniconda3.exe /S /D=C:\Users\Administrator\miniconda3 | more

# Download MSVC Build tools 2015
RUN powershell -Command " \
    $url = \"http://go.microsoft.com/fwlink/?LinkId=691126\"; \
    $client = new-object System.Net.WebClient; \
    $client.DownloadFile( $url, \"msvc_build_tools.exe\"); \
    "

# Install MSVC build tools 2015
RUN msvc_build_tools.exe /full /q | more

# What the previous command would look like with logging enabled:
# RUN msvc_build_tools.exe /full /q /l msvc_build_tools_log.txt | more

# A similar technique should (but doesn't currently) work to
# install older MSVC compilers.
# See also:
# https://windowsserver.uservoice.com/forums/295047-general-feedback/suggestions/13398387-make-older-visual-studio-versions-install-correctl

# Download and install 7zip.
# This is generally useful
RUN powershell -Command " \
    $url = \"http://www.7-zip.org/a/7z1514-x64.exe\"; \
    $client = new-object System.Net.WebClient; \
    $client.DownloadFile( $url, \"7zip_15_14.exe\"); \
    "

RUN 7zip_15_14.exe /S | more

# Download and install Dependency Walker.
# This is useful for debugging issues that may come up.
RUN powershell -Command " \
    $url = \"http://www.dependencywalker.com/depends22_x64.zip\"; \
    $client = new-object System.Net.WebClient; \
    $client.DownloadFile( $url, \"dependency_walker.zip\"); \
    "
# Use 7-zip to unzip the dependency walker folder.
# The "| Write-Output" idiom serves the same function as the
# "| more" idiom in cmd. It prevents a program from returning
# an exit status before completing.
RUN powershell -Command "& \"C:/Program Files/7-zip/7z.exe\" x dependency_walker.zip \"*.*\" -odependency_walker -y -r | Write-Output"

# Appending to the existing path wasn't working in the Dockerfile,
# So set the full system path here. The first part is the default.
# The last bit is the part added in this Dockerfile.
ENV PATH=C:\\Windows\\system32;C:\\Windows;C:\Windows\\System32\\Wbem;C:\\Windows\\System32\\WindowsPowerShell\\v1.0;C:\\Users\\Administrator\\miniconda3;C:\\Users\\Administrator\\miniconda3\\Scripts;C:\\Users\\Administrator\\miniconda3\\Library\\bin;C:\\Program\ Files\\7-zip;C:\\Users\\Administrator\\dependency_walker

# Due to https://github.com/docker/docker/issues/22209
# .condarc doesn't persist in the docker image yet, so we need to explicitly
# provide the -y flag to each conda command for the time being.
# This has already been fixed upstream and should no longer be
# an issue with the TP5 release of Windows Server 2016.

# Likely due to the same issue as the installer fail, the menus don't
# install properly, so we need to guard against the command stopping
# docker from finishing building the Dockerfile.
RUN conda install -y git && exit 0
RUN conda install -y svn
RUN conda install -y anaconda-client
RUN conda install -y anaconda-build
RUN conda clean --all -y

We may be able to work around the menu installation issues by changing some error handling in menuinst. I'm still investigating that.

[insertinterestingnamehere]

Just submitted https://social.msdn.microsoft.com/Forums/en-US/a3953797-fe89-4acc-89d5-756354fbaac4/installing-older-versions-of-visual-studio-in-containers?forum=windowscontainers upstream as well since it appears to be a more appropriate place for bug reports like that one.

[insertinterestingnamehere]

Submitted Docker issues:

1. https://github.com/docker/docker/issues/22169 (major pain point, mostly worked around)
2. https://github.com/docker/docker/issues/21697 (not blocking, just a weird thing to be aware of)
3. https://github.com/docker/docker/issues/22209 (already fixed in TP5, but prevents persistent .condarc in image)
4. https://social.msdn.microsoft.com/Forums/en-US/a3953797-fe89-4acc-89d5-756354fbaac4/installing-older-versions-of-visual-studio-in-containers?forum=windowscontainers (Prevents using C/C++ compilers for older Python versions, needs fixing upstream)
5. https://github.com/ContinuumIO/anaconda-issues/issues/753 (the "fix" already applied makes it no longer a blocker here, but it's still a serious issue with the scipy conda package)

I think we can work around item 1 with some small changes either in menuinst or in both conda and constructor. There are a few other miscellaneous non-blocking issues I need to report upstream as well.

[insertinterestingnamehere]

https://github.com/docker/docker/issues/22232 is another non-blocking oddity.

[insertinterestingnamehere]

Another non-blocking issue is that the USER command in a dockerfile isn't currently supported. That appears to already be a known thing though. See https://github.com/docker/docker/blob/07f580489908bf6a3373daac1473045406e1130d/builder/dockerfile/evaluator_windows.go#L9.

[insertinterestingnamehere]

Useful related links for anyone interested: known outstanding issues: https://msdn.microsoft.com/virtualization/windowscontainers/about/work_in_progress various working examples: https://github.com/Microsoft/Virtualization-Documentation/tree/master/windows-container-samples/windowsservercore particularly helpful docs: https://msdn.microsoft.com/en-us/virtualization/windowscontainers/about/about_overview https://msdn.microsoft.com/en-us/virtualization/windowscontainers/quick_start/azure_setup https://msdn.microsoft.com/en-us/virtualization/windowscontainers/quick_start/inplace_setup (the script mentioned in that last one can be run without -HyperV flag to install only the containers that don't require virtualization)

[insertinterestingnamehere]

https://windowsserver.uservoice.com/forums/304624-containers/suggestions/13398387-make-older-visual-studio-versions-install-correctl is another one I submitted, but there hasn't been any acknowledgement of the issue there, so I went ahead and submitted https://social.msdn.microsoft.com/Forums/en-US/a3953797-fe89-4acc-89d5-756354fbaac4/installing-older-versions-of-visual-studio-in-containers?forum=windowscontainers as well. It's not clear to me if that's an issue with docker or with the windows server docker image, so I submitted it on their issues forum rather than on the docker repo.

[insertinterestingnamehere]

Changing https://github.com/conda/constructor/blob/master/constructor/nsis/_nsis.py#L69 to read except (ImportError, WindowsError): is an alternative workaround for the miniconda installer freeze. That indicates to me that https://github.com/docker/docker/issues/22169 really is the issue causing trouble here. One possible solution on our end is to just have menuinst raise an import error rather than a Windows error when these directories can't be found. Both in conda and in constructor, if menuinst fails to import with an import error, the error is silenced. I've attempted a fix in https://github.com/ContinuumIO/menuinst/pull/28, though I'm not entirely sure what a better way to test those changes is. @msarahan any thoughts?

[msarahan]

Sorry I'm slow here. Why an ImportError and not an IOError or something like that? I'm all for avoiding the issue by changing the exception, but I want to choose the most meaningful exception. I wrote some pretty high-level tests in https://github.com/ContinuumIO/menuinst/pull/27/files - I'll merge that PR. If your changes pass those tests, I think it's good to go.

[insertinterestingnamehere]

The biggest reason for the ImportError is to make it so that we don't get a hard error at https://github.com/conda/constructor/blob/94e380979003878af5f2cbc51d05f47946845302/constructor/nsis/_nsis.py#L69 and https://github.com/conda/conda/blob/0f1cec64058672d2a9c4b793a3041f85a71e4230/conda/install.py#L414. It may make just as much sense to modify those two places to catch the WindowsError from menuinst instead. Looking at the Python docs again, it looks like import errors are specifically for when a module can't be found, not for when it fails to import for some other reason, so the modification is probably better made in conda and constructor.

[insertinterestingnamehere]

It's not entirely clear to me what the conda code is doing in this case anyway. It warns, then logs an error, but the command appears to execute successfully. Hmm.

[insertinterestingnamehere]

Okay, most of the serious errors appear to be fixed in the new Windows Server 2016 TP 5 release. In particular, the miniconda installer works fine now. I went ahead and submitted https://github.com/conda/constructor/pull/22 anyway though.

I also investigated what was going on with the older MSVC versions a bit more, and it appears that the issue is that the installers refuse to run on a system running a trial or technical preview version of Windows, so those are still a no-go for the time being. Thankfully, the MSVC 2015 build tools work fine.

[msarahan]

Interesting! Thanks for chasing this.

On Fri, Apr 29, 2016 at 5:40 PM Ian Henriksen notifications@github.com wrote:

Okay, most of the serious errors appear to be fixed in the new Windows Server 2016 TP 5 release. In particular, the miniconda installer works fine now. I went ahead and submitted conda/constructor#22 https://github.com/conda/constructor/pull/22 anyway though.

I also investigated what was going on with the older MSVC versions a bit more, and it appears that the issue is that the installers refuse to run on a system running a trial or technical preview version of Windows, so those are still a no-go for the time being. Thankfully, the MSVC 2015 build tools work fine.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/Anaconda-Platform/anaconda-build/issues/275#issuecomment-215900020