Move of pythonservice.exe not compatible with virtualenv

[lambacck]

In my environment I install Pywin32 into the site-packages folder of Python and then use virtualenv --system-site-packages for individual applications. This used to work properly but now I'm getting:

STDOUT: moving host exe 'C:\python312\Lib\site-packages\win32\pythonservice.exe' -> 'd:\cioc\PythonEnvs\CommunityRepoPy312v1\pythonservice.exe'
Failed to move host exe '(17, 'MoveFileEx', 'The system cannot move the file to a different disk drive.')'
STDERR: Traceback (most recent call last):
  File "d:\cioc\VirtualServers\CommunityRepo\python\wsgisvc.py", line 373, in <module>
    main()
  File "d:\cioc\VirtualServers\CommunityRepo\python\wsgisvc.py", line 369, in main
    handle_command_line(argv=sys.argv)
  File "d:\cioc\VirtualServers\CommunityRepo\python\wsgisvc.py", line 288, in handle_command_line
    win32serviceutil.HandleCommandLine(
  File "C:\python312\Lib\site-packages\win32\lib\win32serviceutil.py", line 907, in HandleCommandLine
    ChangeServiceConfig(
  File "C:\python312\Lib\site-packages\win32\lib\win32serviceutil.py", line 302, in ChangeServiceConfig
    exeName = '"%s"' % LocatePythonServiceExe(exeName)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\python312\Lib\site-packages\win32\lib\win32serviceutil.py", line 62, in LocatePythonServiceExe
    raise error(f"Can't find '{correct}'")
RuntimeError: Can't find 'd:\cioc\PythonEnvs\CommunityRepoPy312v1\pythonservice.exe'

It looks like #2251 changed the behavior of getting pythinservice.exe into the scripts folder. Previously this used CopyFile and now it uses MoveFileEx which doesn't work across drives. This would work for the first virtualenv if the virtualenv was on the same drive as the Python where pywin32 was installed, the move would mean that other virtualenvs would not work because pythonservice.exe would no longer be available to be copied.

System information

Python.org build of Python 3.12.10 Windows 64-bit installed for all users.

pywin32 version: 311 64-bit

Windows Version:
Edition Windows Server 2022 Datacenter
Version 21H2
Installed on ‎9/‎23/‎2023
OS build 20348.4171

DLL locations:

C:\>c:\python312\python -c "import pywintypes,pythoncom;print(pywintypes.__file__,pythoncom.__file__,sep='\n')"
c:\python312\Lib\site-packages\pywin32_system32\pywintypes312.dll
c:\python312\Lib\site-packages\pywin32_system32\pythoncom312.dll

The above is missleading because those DLLs are also in c:\windows\system32 which was required to get my services working after I manually copied the file and the registry to cause my service to launch.

[mhammond]

I've always thought of services being incompatible with virtualenvs - virtualenvs are kinda transient/temporary, which isn't a great situation for services.

For this particular problem though, it was important that the file not exist in the location it was shipped from, because often the original executable would be found, and it didn't work from that location - so changing back to a copy would obviously revert the problem solved by changing it to a move. I'm open to ideas that solves this though so long as it doesn't regress the non-virtualenv situation, because really that's how services should be run IMO.

[lambacck]

I have several services that have different dependencies. My service files do not assume they are started with the virtualenv activated and instead use activate_this.py to activate the required virtualenv before importing anything not in the stdlib.

Maybe it's a mistake is using python from the virtualenv to register the service and instead I need to change my automation to use the base python. I'll look into that and if it doesn't work, I'll reopen this with a specific change via PR in a couple of days.