@jaraco Can you please review this change?

I'm generally in favor of this change, even though it's adding functionality against a deprecated feature (easy_install wrapper scripts). Do you know what is the status of wrapper scripts in pip for arm on Windows executables? If pip/distutils already supports these, I'll be slightly inclined to leave them broken for easy_install, which is deprecated and to direct users to use pip to install and generate wrapper executables for ARM platforms.

Thanks, @jaraco . pip/distutils is also broken for the time being for woa. I have raised a PR for distutils and after merging and a distlib release the pip needs to be upgraded as well.

I think it will be helpful to have support in easy_install for woa as it might take a while to get woa launcher script support in pip.

Extra voice adding support for fixing this in setuptools, even though easy_install and friends are ye-olde deprecated, it will make working on ARM64 Windows that much more relaxed and nice when dealing with older packages or for some reason or the other being forced to use an older method of installing. Also, it would harmonize the experience of setuptools between the two (three) architectures.

@nsait-linaro: Do you have a link to the distutils PR and possibly a pip issue number with regards to launcher support for pip? I couldn't find it.

@rubin55 Here is the PR for distlib which seems to be the windows launcher used by pip.

And please check pip issue 10489

@jaraco Could you approve the pending workflow and merge the changes if you are happy ?

This change looks good to me, but I need some sort of verification that the changes work as intended... and preferably a verification that the compiled binaries were generated from the supplied sources. To do that, I think I need a machine with a compiler where I can compile the binaries myself. I'll try to acquire one using my MSDN subscription.

Re: workflow failure seems to be due to a network timeout error. I don't see how it is related to my patch so I guess it is a generic issue.

_____________ ERROR collecting setuptools/tests/test_virtualenv.py _____________

setuptools/tests/test_virtualenv.py:99: in <module>
    ???
setuptools/tests/test_virtualenv.py:64: in _get_pip_versions
    urlopen('https://pypi.org', timeout=1)
/opt/hostedtoolcache/Python/3.10.0-rc.2/x64/lib/python3.10/urllib/request.py:216: in urlopen
    return opener.open(url, data, timeout)
/opt/hostedtoolcache/Python/3.10.0-rc.2/x64/lib/python3.10/urllib/request.py:519: in open
    response = self._open(req, data)
/opt/hostedtoolcache/Python/3.10.0-rc.2/x64/lib/python3.10/urllib/request.py:536: in _open
    result = self._call_chain(self.handle_open, protocol, protocol +
/opt/hostedtoolcache/Python/3.10.0-rc.2/x64/lib/python3.10/urllib/request.py:496: in _call_chain
    result = func(*args)
/opt/hostedtoolcache/Python/3.10.0-rc.2/x64/lib/python3.10/urllib/request.py:1391: in https_open
    return self.do_open(http.client.HTTPSConnection, req,
/opt/hostedtoolcache/Python/3.10.0-rc.2/x64/lib/python3.10/urllib/request.py:1352: in do_open
    r = h.getresponse()
/opt/hostedtoolcache/Python/3.10.0-rc.2/x64/lib/python3.10/http/client.py:1368: in getresponse
    response.begin()
/opt/hostedtoolcache/Python/3.10.0-rc.2/x64/lib/python3.10/http/client.py:317: in begin
    version, status, reason = self._read_status()
/opt/hostedtoolcache/Python/3.10.0-rc.2/x64/lib/python3.10/http/client.py:278: in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
/opt/hostedtoolcache/Python/3.10.0-rc.2/x64/lib/python3.10/socket.py:705: in readinto
    return self._sock.recv_into(b)
/opt/hostedtoolcache/Python/3.10.0-rc.2/x64/lib/python3.10/ssl.py:1273: in recv_into
    return self.read(nbytes, buffer)
/opt/hostedtoolcache/Python/3.10.0-rc.2/x64/lib/python3.10/ssl.py:1129: in read
    return self._sslobj.read(len, buffer)
E   TimeoutError: The read operation timed out

This change looks good to me, but I need some sort of verification that the changes work as intended... and preferably a verification that the compiled binaries were generated from the supplied sources. To do that, I think I need a machine with a compiler where I can compile the binaries myself. I'll try to acquire one using my MSDN subscription.

Thanks, @jaraco. Binaries for ARM64 can be cross-compiled from x86 or x64 windows machines. If you prefer you can amend the patch with the new binaries you create locally. I don't think there is any cloud VM available for woa yet so if you update the patch I can test new patch on my win/arm64 machine.

Oh, I hadn't realized the binaries could be cross-compiled. That's great.

Unfortunately, the current msvc_build_launcher.cmd is not working for me, using a recent install of Visual Studio 2019.

The link in that script takes me to a 404 page.

Did you use the script to build the results? If so, what did you do to set it up?

I have been using this Windows Docker container.

Thanks, @jaraco for trying it out. I couldn't install SDK 6.1 as well. I had to use VS 2019 for arm64 launchers. I've added a new script msvc-build-launcher-arm64.cmd to compile arm64 binaries using VS 2019. Could you give it a try with that ?

That's helpful, I think. I did try with the new script, but it also doesn't find visual studio as I've installed it:

PS C:\Program Files (x86)\Microsoft Visual Studio\2019> dir


    Directory: C:\Program Files (x86)\Microsoft Visual Studio\2019


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----        7/13/2021  10:56 AM                BuildTools
d-----        7/13/2021  10:55 AM                TestAgent

It seems I only have MSBuild installed and not Visual Studio. I'm going to have to do more experimentation to determine what components are needed to provide the necessary tools.

Aha. I see now that the Docker image install MSVC into \Buildtools:

PS C:\> . '/Program Files (x86)/Microsoft Visual Studio/installer/vswhere' -latest -products * -property installationPath
C:\BuildTools

I probably installed into that directory because I struggled to install into a directory with spaces due to escaping challenges.

So probably, the script needs to invoke vswhere in order to locate where Visual Studio is installed. It probably should also indicate the required components to include the ARM compiler.

I'd recommend to get away from using a .cmd file. It's a very old syntax with a lot of legacy. I'd recommend to use Python or Powershell to write the script. I don't know if that's possible, though, with the use of "VCVARS*", which uses .bat files. Maybe the setuptools.msvc module provides some guidance on how to locate and invoke VC from Python.

Of course, all of this effort is moot if I can just get a pair of verified binaries. I'm starting to care less about getting a repeatable process as this is all a big mess and deprecated.

I started work on getting ARM support into my Docker image, but the build is failing, and I'm out of time to work on this today. I'll look into this more later.

Thanks, @jaraco. I've tested v58.2.0 and it all seems to work as expected.